[gdal-dev] simple listing of layers by OGR
Hello everybody;
First of all, I would like to say that I am quite new in S-57 format
and GDAL/OGR libraries.
As a starting point, I downloaded the source codes and built the whole
GDAL library on my computer,
using the "nmake" of Visual Studio 2008.
Now:
poDS = OGRSFDriverRegistrar::Open( "US5LA24M.000", FALSE );
for (int i = 0; i < poDS->GetLayerCount(); i++)
printf("layer %d: %s\n", i, poDS->GetLayer(i)->GetLayerDefn()->GetName());
When I try to list the layer names of a datasource with the code snippet above,
I get the following result:
layer 0: DSID
layer 1: Point
layer 2: Line
layer 3: Area
layer 4: Meta
However, the utility application "ogrinfo" gives a quite different
result as follows:
(when run with command "ogrinfo US5LA24M.000" )
1: DSID (None)
2: ACHARE
3: BCNLAT (Point)
4: BCNSPP (Point)
5: BUISGL
...
...
...
49: M_QUAL (Polygon)
50: C_ASSO (None)
I examined the source code of "ogrinfo" under the "gdal-1.6.2\apps\"
directory, however,
I could not find a difference in terms of listing the layers in the dataset.
What could be the problem, is there a point that I'm missing?
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] simple listing of layers by OGR
Hello everybody;
First of all, I would like to say that I am quite new in S-57 format
and GDAL/OGR libraries.
As a starting point, I downloaded the source codes and built the whole
GDAL library on my computer,
using the "nmake" of Visual Studio 2008.
Now:
poDS = OGRSFDriverRegistrar::Open( "US5LA24M.000", FALSE );
for (int i = 0; i < poDS->GetLayerCount(); i++)
printf("layer %d: %s\n", i, poDS->GetLayer(i)->GetLayerDefn()->GetName());
When I try to list the layer names of a datasource with the code snippet above,
I get the following result:
layer 0: DSID
layer 1: Point
layer 2: Line
layer 3: Area
layer 4: Meta
However, the utility application "ogrinfo" gives a quite different
result as follows:
(when run with command "ogrinfo US5LA24M.000" )
1: DSID (None)
2: ACHARE
3: BCNLAT (Point)
4: BCNSPP (Point)
5: BUISGL
...
...
...
49: M_QUAL (Polygon)
50: C_ASSO (None)
I examined the source code of "ogrinfo" under the "gdal-1.6.2\apps\"
directory, however,
I could not find a difference in terms of listing the layers in the dataset.
What could be the problem, is there a point that I'm missing?
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] simple listing of layers by OGR
Frank, thank you very much for the answer.
Yes, I use the "ogrinfo" application that comes with the FWTools installation.
( Thanks by the way for this wonderful set of tools )
For my own application, I just built the GDAL library with
default configuration options, just changing the compiler
version to 1500 (stating that I'm using Visual Studio 2008)
Ok, let me apply the changes that you proposed.
Best regards,
Yilmaz
On Thu, Sep 17, 2009 at 10:16 PM, Frank Warmerdam wrote:
> Yilmaz Arslanoglu wrote:
>>
>> Hello everybody;
>>
>> First of all, I would like to say that I am quite new in S-57 format
>> and GDAL/OGR libraries.
>>
>> As a starting point, I downloaded the source codes and built the whole
>> GDAL library on my computer,
>> using the "nmake" of Visual Studio 2008.
>>
>> Now:
>>
>> poDS = OGRSFDriverRegistrar::Open( "US5LA24M.000", FALSE );
>> for (int i = 0; i < poDS->GetLayerCount(); i++)
>> printf("layer %d: %s\n", i,
>> poDS->GetLayer(i)->GetLayerDefn()->GetName());
>>
>> When I try to list the layer names of a datasource with the code snippet
>> above,
>> I get the following result:
>>
>> layer 0: DSID
>> layer 1: Point
>> layer 2: Line
>> layer 3: Area
>> layer 4: Meta
>>
>> However, the utility application "ogrinfo" gives a quite different
>> result as follows:
>> (when run with command "ogrinfo US5LA24M.000" )
>>
>> 1: DSID (None)
>> 2: ACHARE
>> 3: BCNLAT (Point)
>> 4: BCNSPP (Point)
>> 5: BUISGL
>> ...
>> ...
>> ...
>> 49: M_QUAL (Polygon)
>> 50: C_ASSO (None)
>>
>> I examined the source code of "ogrinfo" under the "gdal-1.6.2\apps\"
>> directory, however,
>> I could not find a difference in terms of listing the layers in the
>> dataset.
>>
>> What could be the problem, is there a point that I'm missing?
>
> Yilmaz,
>
> In the case where you only get DSID, Point, Line, Area and Meta
> layers the OGR S-57 driver was unable to find the s57 object class
> .csv files at runtime in order to properly categorize things in
> feature classes.
>
> This might be accomplished by setting the GDAL_DATA configuration
> variable either via the environment or the CPLSetConfigOption()
> function. Were you using ogrinfo from an environment like
> OSGeo4W or FWTools that sets up the environment carefully?
>
> In some form this question needs to be in the FAQ!
>
> 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
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] OGRGeometry Distance
Hi all; I wanted to compute the distance between two points, and for this reason I tried the "OGRGeometry::Distance" member function. However, I saw that this function only returns the linear distance between the objects, regardless of their geospatial reference. (as it is also stated somewhere on the net that GEOS library implements it this way) So I would like to compute the actual distance between the points, let's say, 23 degrees north, 30 degrees east and 25 degrees west, -5 degrees east. My question is, do we need to implement this functionality by using projection transformations etc., or is there an easy way to do this using the OGR library? Also, as another related question, I query the DEPCNT layer in one of my ENC files, and it has a geospatial reference. However, the points on the line string features themselves return NULL when they are queried with getSpatialReference(). Aren't they expected to return exactly the same instance for the layer that they reside on? Regards, Yilmaz ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGRGeometry Distance
Hi Even; Thank you very much for your help. Regards, Yilmaz On Mon, Sep 21, 2009 at 9:37 PM, Even Rouault wrote: > Selon Christopher Barker : > > I'd note that in the OGR XPlane driver, a function is available to compute the > distance on the spheroid. You could use it if you don't need much accuracy : > http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrsf_frmts/xplane/ogr_xplane_geo_utils.cpp > > (It's an internal function to OGR, so you'd have to copy&paste it in your > code, > or add a CPL_DLL decoration in the corresponding .h and rebuild GDAL) > >> Yilmaz Arslanoglu wrote: >> > I wanted to compute the distance between two points, >> >> you need to be clear by what you mean here: I suspect you mean: >> >> "The shortest distance between two points following the surface of the >> earth" >> >> In which case, what you are looking for is referred to as the geodesic >> distance: >> >> http://www.vterrain.org/Misc/distance.html >> >> To do this accurately (and you may not need much accuracy!) on an >> ellipsoid requires a fair bit of math. I don't know if it's built in to >> OGR or PROJ at this point, but there are a few libraries out that that >> do it, including Gerald I. Evenden's "geodesic" lib, which can be found >> here: >> >> http://home.comcast.net/~gevenden56/geodesy/project/ >> >> -Chris >> >> >> >> -- >> Christopher Barker, Ph.D. >> Oceanographer >> >> Emergency Response Division >> NOAA/NOS/OR&R (206) 526-6959 voice >> 7600 Sand Point Way NE (206) 526-6329 fax >> Seattle, WA 98115 (206) 526-6317 main reception >> >> chris.bar...@noaa.gov >> ___ >> 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] OGRGeometry Distance
Thanks very much for the answer, Frank. Best wishes, Yilmaz On Mon, Sep 21, 2009 at 10:12 PM, Frank Warmerdam wrote: > Yilmaz Arslanoglu wrote: >> >> Also, as another related question, I query the DEPCNT layer in one of >> my ENC files, and it has a geospatial reference. >> However, the points on the line string features themselves return NULL >> when they are queried with getSpatialReference(). >> Aren't they expected to return exactly the same instance for the layer >> that they reside on? > > Yilmaz, > > Others have addressed the geodesic distance issue. > > On the spatial reference issue, you are correct. The geometry from the > layers ought to return a pointer to the same spatial reference object > as you see on the layer. It is a defect of the S-57 driver (and I suspect > a number of others) that this is not done. If you like, you could file > a ticket on this and someone could fix it up. > > In practice the spatial references attached to the geometries are rarely > consulted by applications and so are often not set properly by drivers. > > 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 > > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: OGRGeometry Distance
>>you need to be clear by what you mean here: I suspect you mean: >> >>"The shortest distance between two points following the surface of the >>earth" Yes Chris, you are right. Actually my purpose is to make a bathymetric prediction of a given position, with the help of the contours and sounding points at hand. I just thought that it would be a better idea to take shortest distances in calculations (maybe the Kriging) rather than using pure lat-lon values. So does it make sense to use the geodesic distances for the closeness criteria? ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] sounding point handling by OGR library
Hi;
I had some questions regarding the additional feature of sounding
point handling by the OGR library.
I know that we need to turn on the options SPLIT_MULTIPOINT and
ADD_SOUNDG_DEPTH options on.
1) Is there a way to turn them individually on without affecting the
other suboptions in OGR_S57_OPTIONS ?
Because if we do it by the following statement:
CPLSetConfigOption("OGR_S57_OPTIONS",
"SPLIT_MULTIPOINT=ON,ADD_SOUNDG_DEPTH=ON");
Then there is a possibility to overwrite the other suboptions
UPDATES, RETURN_PRIMITIVES,
PRESERVE_EMPTY_NUMBERS, LNAM_REFS, and RETURN_LINKAGES.
2) With turning ADD_SOUNDG_DEPTH option on, the points become three
dimensional, where the Z
member variable contains the retrieved depth value I guess. Here,
my question is, does this depth
retrieval process take care of any unit conversions (meters,
fathoms, feet, etc.) ?
Regards,
Yilmaz
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] sounding point handling by OGR library
Thank you very much Frank for the quick and clear answers.
Best wishes,
Yilmaz
On Tue, Sep 29, 2009 at 6:20 PM, Frank Warmerdam wrote:
> Yilmaz Arslanoglu wrote:
>>
>> Hi;
>>
>> I had some questions regarding the additional feature of sounding
>> point handling by the OGR library.
>>
>> I know that we need to turn on the options SPLIT_MULTIPOINT and
>> ADD_SOUNDG_DEPTH options on.
>>
>> 1) Is there a way to turn them individually on without affecting the
>> other suboptions in OGR_S57_OPTIONS ?
>> Because if we do it by the following statement:
>>
>> CPLSetConfigOption("OGR_S57_OPTIONS",
>> "SPLIT_MULTIPOINT=ON,ADD_SOUNDG_DEPTH=ON");
>>
>> Then there is a possibility to overwrite the other suboptions
>> UPDATES, RETURN_PRIMITIVES,
>> PRESERVE_EMPTY_NUMBERS, LNAM_REFS, and RETURN_LINKAGES.
>
> Yilmaz,
>
> You are correct, calling CPLSetConfigOption() will clear the previous
> setting, so if you want things amalgamated you need to do it
> yourself in code in some fashion.
>
>> 2) With turning ADD_SOUNDG_DEPTH option on, the points become three
>> dimensional, where the Z
>> member variable contains the retrieved depth value I guess. Here,
>> my question is, does this depth
>> retrieval process take care of any unit conversions (meters,
>> fathoms, feet, etc.) ?
>
> I do not believe it is doing any unit conversion. You will
> get a Z coordinate in the depth units that it appears in
> the depth attribute.
>
> In general OGR and OGRSpatialReference do not attempt to
> address the units of Z values even though there is an OGC
> coverage of compound (ie. 2D + elevation) coordinate systems.
>
> 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
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] compiling GDAL with GEOS on Windows
Hi; I am trying to build and install the GDAL library on Windows XP using the following commands: nmake /f makefile.vc nmake /f makefile.vc install nmake /f makefile.vc devinstall In order to build with GEOS support, I uncommented the lines in the "nmake.opt" as follows: GEOS_DIR=C:\geos-3.1.1 GEOS_CFLAGS = -I$(GEOS_DIR)/capi -I$(GEOS_DIR)/source/headers -DHAVE_GEOS GEOS_LIB = $(GEOS_DIR)/source/geos_c_i.lib However, I still get the same .dll and .lib files as if no GEOS support was turned on (the sizes are exactly the same). When I try to call "OGRGeometry::Contains()" method, I also get the error: "ERROR 6: GEOS support not enabled." What could be wrong? 2) I was also wondering whether OGR library provides a kind of nearest neighbour finding facilities? If not, does anybody know any library that could be integrated with OGR for this purpose? I plan to use it to find the n nearest sounding points (SOUNDG) given a point, to make a prediction about its depth. 3) Finally, is there any facility in OGR for querying a layer such that it will only return the features on it, which contain a given point as parameter? Because I could not come up with an SQL statement to perform this task. Actually I was planning to use this on the DEPARE (depth area) layer on an S-57 file to find the depth area polygon that covers the given point. Any idea or references about these issues would greatly be appreciated. Best regards, Yilmaz ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] compiling GDAL with GEOS on Windows
Hi Frank; > Make sure you do a "nmake /f makefile.vc clean" after any change to Thank you very much, actually I should have already thought this before :) Now it runs quite OK. > If you specify a point to OGRLayer::SetSpatialFilter() you should only > get back features that intersect that point. Then do you have an idea how the "intersect" would behave between a line string and a point? (I would expect TRUE if the point lies on any of the line string legs, FALSE otherwise) I'm asking since DEPARE layer may also contain line string features besides polygon features. (or shouldn't this happen at all?) On Thu, Oct 1, 2009 at 7:00 PM, Frank Warmerdam wrote: > Yilmaz Arslanoglu wrote: >> >> Hi; >> >> I am trying to build and install the GDAL library on Windows XP >> using the following commands: >> >> nmake /f makefile.vc >> nmake /f makefile.vc install >> nmake /f makefile.vc devinstall >> >> In order to build with GEOS support, I uncommented the lines >> in the "nmake.opt" as follows: >> >> GEOS_DIR=C:\geos-3.1.1 >> GEOS_CFLAGS = -I$(GEOS_DIR)/capi -I$(GEOS_DIR)/source/headers -DHAVE_GEOS >> GEOS_LIB = $(GEOS_DIR)/source/geos_c_i.lib >> >> However, I still get the same .dll and .lib files as if no GEOS >> support was turned on > > Yilmaz, > > Make sure you do a "nmake /f makefile.vc clean" after any change to > the nmake.opt file. The makefiles are not setup to force a full > rebuild on changes to the nmake.opt file or sub-makefiles. > >> 2) I was also wondering whether OGR library provides a kind of nearest >> neighbour finding facilities? >> If not, does anybody know any library that could be integrated with >> OGR for this purpose? >> I plan to use it to find the n nearest sounding points (SOUNDG) >> given a point, to make a prediction >> about its depth. > > Nothing comes to mind to address this. > >> 3) Finally, is there any facility in OGR for querying a layer such that >> it will only return the features on it, which contain a given >> point as parameter? >> Because I could not come up with an SQL statement to perform this task. >> Actually I was planning to use this on the DEPARE (depth area) layer on >> an S-57 file to find the depth area polygon that covers the given >> point. > > If you specify a point to OGRLayer::SetSpatialFilter() you should only > get back features that intersect that point. Without GEOS you would get > any feature whose bounding box contained that point but with GEOS the > test should be more precise. > > 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 > > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] compiling GDAL with GEOS on Windows
Hi Bhasker; I use Visual Studio 2008, but actually the problem was forgetting to make a complete clean before building it with the modified options. So as Frank said, it will be nice to call "nmake /f makefile.vc clean" before the build. Regards, Yilmaz On Fri, Oct 2, 2009 at 9:14 AM, spbhasker bachi wrote: > hi. > which version of vc++ are you using.. > coz if u are using vc++ 6.0 you need to make some changes in some codes. > also do study the nmake.opt file & check i all the paths are set properly. > hope this helps.. > bhasker > > On Thu, Oct 1, 2009 at 10:24 PM, Yilmaz Arslanoglu > wrote: >> >> Hi; >> >> I am trying to build and install the GDAL library on Windows XP >> using the following commands: >> >> nmake /f makefile.vc >> nmake /f makefile.vc install >> nmake /f makefile.vc devinstall >> >> In order to build with GEOS support, I uncommented the lines >> in the "nmake.opt" as follows: >> >> GEOS_DIR=C:\geos-3.1.1 >> GEOS_CFLAGS = -I$(GEOS_DIR)/capi -I$(GEOS_DIR)/source/headers -DHAVE_GEOS >> GEOS_LIB = $(GEOS_DIR)/source/geos_c_i.lib >> >> However, I still get the same .dll and .lib files as if no GEOS >> support was turned on >> (the sizes are exactly the same). When I try to call >> "OGRGeometry::Contains()" method, >> I also get the error: >> >> "ERROR 6: GEOS support not enabled." >> >> What could be wrong? >> >> 2) I was also wondering whether OGR library provides a kind of nearest >> neighbour finding facilities? >> If not, does anybody know any library that could be integrated with >> OGR for this purpose? >> I plan to use it to find the n nearest sounding points (SOUNDG) >> given a point, to make a prediction >> about its depth. >> >> 3) Finally, is there any facility in OGR for querying a layer such that >> it will only return the features on it, which contain a given >> point as parameter? >> Because I could not come up with an SQL statement to perform this task. >> Actually I was planning to use this on the DEPARE (depth area) layer on >> an S-57 file to find the depth area polygon that covers the given >> point. >> >> Any idea or references about these issues would greatly be >> appreciated. >> >> Best regards, >> Yilmaz >> ___ >> 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] compiling GDAL with GEOS on Windows
Hi Peter; Thank you very much for the references. Actually I was considering too to utilize the Natural Neighbours concept, not only for nearest neighbour identification, but also for interpolating the values attributed to spatial points. I guess this time a dynamic version of needs to be implemented, since one needs to adapt the tesellation with the newly inserted query point at eachnew query. (assume that I have a set of points with their associated depth values, and I use this set as a source of querying new points with unknown depth) Actually if it is not a problem for you, I would be pleased to see the code to get a better understanding about the algorithms involved. Best regards, Yilmaz On Fri, Oct 2, 2009 at 8:24 AM, Peter J Halls wrote: > Yilmaz, > > I'll leave the GEOS / Windows compilation bit to those who know! However, > I can help on the nearest neighbour issue as I have done some research in > this area. To do it properly is non-trivial: indeed, it is effectively a > Dirichlet / Voronoi tessellation problem. For an outline and some > bibliography see > Halls, P.J, Bulling, M., White, P.C.L., Garland, L., Harris, S., 2001, > Dirichlet neighbours: revisiting Dirichlet tessellation for neighbourhood > analysis, Computers, Environment and Urban Systems (CEUS) 25 pp105-117. > This is based on Robin Sibson and Peter Green's 'Natural Neighbours' > algorithm, Green, P., & Sibson, R, 1978, Computing Dirichlet tessellations > in the plane; Computer Journal 21 pp168-173. > This approach appears to be one of the fastest and most reliable algorithms > for computing a Dirichlet Tessellation. Once you have that tessellation, > the neighbours of each point are easy to identify - indeed, they 'fall out' > of the structure used by the Green and Sibson algorithm. > > My software is written in Simula (the 'original' object programming > language), using the CIM Open Source Simula cross-compiler from the > University of Oslo and the OGR library via c calls. My 'neighbours' program > computes for each point in a dataset the set of 'natural neighbours' for > each point, identifies that which is nearest and reports the distances and > angles to each neighbour. CIM is written in c and cross compiles into c. I > use the Cygwin interface on Windows and the gcc compilers: I cannot comment > on building CIM in Visual Studio. However, should you wish, I would be > willing to supply you with my source. > > Best wishes, > > Peter > > Yilmaz Arslanoglu wrote: >> >> Hi; >> >> I am trying to build and install the GDAL library on Windows XP >> using the following commands: >> >> nmake /f makefile.vc >> nmake /f makefile.vc install >> nmake /f makefile.vc devinstall >> >> In order to build with GEOS support, I uncommented the lines >> in the "nmake.opt" as follows: >> >> GEOS_DIR=C:\geos-3.1.1 >> GEOS_CFLAGS = -I$(GEOS_DIR)/capi -I$(GEOS_DIR)/source/headers -DHAVE_GEOS >> GEOS_LIB = $(GEOS_DIR)/source/geos_c_i.lib >> >> However, I still get the same .dll and .lib files as if no GEOS >> support was turned on >> (the sizes are exactly the same). When I try to call >> "OGRGeometry::Contains()" method, >> I also get the error: >> >> "ERROR 6: GEOS support not enabled." >> >> What could be wrong? >> >> 2) I was also wondering whether OGR library provides a kind of nearest >> neighbour finding facilities? >> If not, does anybody know any library that could be integrated with >> OGR for this purpose? >> I plan to use it to find the n nearest sounding points (SOUNDG) >> given a point, to make a prediction >> about its depth. >> >> 3) Finally, is there any facility in OGR for querying a layer such that >> it will only return the features on it, which contain a given >> point as parameter? >> Because I could not come up with an SQL statement to perform this task. >> Actually I was planning to use this on the DEPARE (depth area) layer on >> an S-57 file to find the depth area polygon that covers the given >> point. >> >> Any idea or references about these issues would greatly be >> appreciated. >> >> Best regards, >> Yilmaz >> ___ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > > -- > > Peter J Halls, GIS Advisor, University of York > Telephone: 01904 433806 Fax: 01904 433740 > Snail mail: Computing Service, 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
[gdal-dev] Re: compiling GDAL with GEOS on Windows
Yes Chris, the first one ( "triangle" ) has licensing problems, and "natgrid" only comes with the NCL. I downloaded NCL source, but it says that it can only be compiled for Unix environment. Actually, Dave F. Watson's original code (which natgrid is actually based upon) seems to do what I need, but all links to the source are inaccessible. Do you have any idea how to access this original code? I hope its license is also appropriate. >As it happens, I need to do something very similar soon, so I'd love to >hear what you come up with. Sure, I'd be pleased to share results that I obtain and the solutions that I hopefully come up with. Best regards, Yilmaz ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] randyqi...@hotmail.com
Hi Randy;
Did you check that you set the GDAL_DATA configuration correctly?
If it is the case, then here is the previous answer from Frank:
"This might be accomplished by setting the GDAL_DATA configuration
variable either via the environment or the CPLSetConfigOption()
function. Were you using ogrinfo from an environment like
OSGeo4W or FWTools that sets up the environment carefully?"
And my question was:
-
Hello everybody;
First of all, I would like to say that I am quite new in S-57 format
and GDAL/OGR libraries.
As a starting point, I downloaded the source codes and built the whole
GDAL library on my computer,
using the "nmake" of Visual Studio 2008.
Now:
poDS = OGRSFDriverRegistrar::Open( "US5LA24M.000", FALSE );
for (int i = 0; i < poDS->GetLayerCount(); i++)
printf("layer %d: %s\n", i, poDS->GetLayer(i)->GetLayerDefn()->GetName());
When I try to list the layer names of a datasource with the code snippet above,
I get the following result:
layer 0: DSID
layer 1: Point
layer 2: Line
layer 3: Area
layer 4: Meta
However, the utility application "ogrinfo" gives a quite different
result as follows:
(when run with command "ogrinfo US5LA24M.000" )
1: DSID (None)
2: ACHARE
3: BCNLAT (Point)
4: BCNSPP (Point)
5: BUISGL
...
...
...
49: M_QUAL (Polygon)
50: C_ASSO (None)
I examined the source code of "ogrinfo" under the "gdal-1.6.2\apps\"
directory, however,
I could not find a difference in terms of listing the layers in the dataset.
What could be the problem, is there a point that I'm missing?
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: randyqi...@hotmail.com
I'm very sorry, I made a wrong copy-paste in the subject field I think :)
On Sun, Oct 11, 2009 at 3:53 PM, Yilmaz Arslanoglu
wrote:
> Hi Randy;
>
> Did you check that you set the GDAL_DATA configuration correctly?
>
> If it is the case, then here is the previous answer from Frank:
>
> "This might be accomplished by setting the GDAL_DATA configuration
> variable either via the environment or the CPLSetConfigOption()
> function. Were you using ogrinfo from an environment like
> OSGeo4W or FWTools that sets up the environment carefully?"
>
> And my question was:
> -
>
> Hello everybody;
>
> First of all, I would like to say that I am quite new in S-57 format
> and GDAL/OGR libraries.
>
> As a starting point, I downloaded the source codes and built the whole
> GDAL library on my computer,
> using the "nmake" of Visual Studio 2008.
>
> Now:
>
> poDS = OGRSFDriverRegistrar::Open( "US5LA24M.000", FALSE );
> for (int i = 0; i < poDS->GetLayerCount(); i++)
> printf("layer %d: %s\n", i, poDS->GetLayer(i)->GetLayerDefn()->GetName());
>
> When I try to list the layer names of a datasource with the code snippet
> above,
> I get the following result:
>
> layer 0: DSID
> layer 1: Point
> layer 2: Line
> layer 3: Area
> layer 4: Meta
>
> However, the utility application "ogrinfo" gives a quite different
> result as follows:
> (when run with command "ogrinfo US5LA24M.000" )
>
> 1: DSID (None)
> 2: ACHARE
> 3: BCNLAT (Point)
> 4: BCNSPP (Point)
> 5: BUISGL
> ...
> ...
> ...
> 49: M_QUAL (Polygon)
> 50: C_ASSO (None)
>
> I examined the source code of "ogrinfo" under the "gdal-1.6.2\apps\"
> directory, however,
> I could not find a difference in terms of listing the layers in the dataset.
>
> What could be the problem, is there a point that I'm missing?
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] different result of ogrinfo between GDAL/OGR and FWTools
Hi Randy;
Did you check that you set the GDAL_DATA configuration correctly?
If it is the case, then here is the previous answer from Frank:
"This might be accomplished by setting the GDAL_DATA configuration
variable either via the environment or the CPLSetConfigOption()
function. Were you using ogrinfo from an environment like
OSGeo4W or FWTools that sets up the environment carefully?"
And my question was:
-
Hello everybody;
First of all, I would like to say that I am quite new in S-57 format
and GDAL/OGR libraries.
As a starting point, I downloaded the source codes and built the whole
GDAL library on my computer,
using the "nmake" of Visual Studio 2008.
Now:
poDS = OGRSFDriverRegistrar::Open( "US5LA24M.000", FALSE );
for (int i = 0; i < poDS->GetLayerCount(); i++)
printf("layer %d: %s\n", i, poDS->GetLayer(i)->GetLayerDefn()->GetName());
When I try to list the layer names of a datasource with the code snippet above,
I get the following result:
layer 0: DSID
layer 1: Point
layer 2: Line
layer 3: Area
layer 4: Meta
However, the utility application "ogrinfo" gives a quite different
result as follows:
(when run with command "ogrinfo US5LA24M.000" )
1: DSID (None)
2: ACHARE
3: BCNLAT (Point)
4: BCNSPP (Point)
5: BUISGL
...
...
...
49: M_QUAL (Polygon)
50: C_ASSO (None)
I examined the source code of "ogrinfo" under the "gdal-1.6.2\apps\"
directory, however,
I could not find a difference in terms of listing the layers in the dataset.
What could be the problem, is there a point that I'm missing?
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] efficient querying of land and depth areas
Hello everybody; I am using the OGR library to extract depth and land areas from an ENC file (S-57 format). What I want to do is to query whether a given point is on land or is on a depth area. For this purpose, I have to call OGRGeometry::Intersects or OGRGeometry::Contains functions for every polygon feature on one of these layers. (similarly, setting the point by SetSpatialFilter on one of these layers also does the job) I tried these and they work quite OK, but unfortunately quite inefficient at the same time. Is there anybody who can offer any tips or references about efficient querying? Best regards, Yilmaz ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] opening an S-57 dataset directory
Hello everybody; I was just wondering whether there is a specific directory structure that needs to be followed in order to open an S-57 file collection by giving a single directory path, instead of a file with a .000 extension. I'm asking because, according to the following statement from OGR IHO S-57 (ENC) Driver documentation, we would be able to pass a directory name. >> An S-57 dataset can be a directory (in which case all S-57 files in the >> directory are selected), >> an S-57 catalog file (in which case all files referred to from the catalog >> are selected) or an individual S-57 data file. However, when I try to open with a directory name using "OGRSFDriverRegistrar::Open", I get an error. As another question: >> S-57 update files contain information on how to update a distributed S-57 >> base data file. >> The base files normally have the extension .000 while the update files have >> extensions like .001, .002 and so on. >> The S-57 reader will normally read and apply all updates files to the in >> memory version of the base file on the fly. >> The feature data provided to the application therefore includes all the >> updates. So how OGR decides to look for the extension files? Because as far as I can see, ENC catalogues may come with different directory structures, where in some of them all update files accompany the original one in the same directory, however they may also come in another directory in some others. Best regards, Yilmaz ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] opening an S-57 dataset directory
Ok Frank, thank you very much for the answer. Actually, under the "gdal/frmts/iso8211" directory, I found the class called "DDFModule" which can open both individual ENC files (*.000) and ENC catalogue files (*.031) Now I use this class to open the catalogue file, get the paths of all relevant files that I need (according to their coverage, since catalogue file contains this information also), and only open these files as OGR datasets. However, if there is no catalogue file, I recursively search the given directory, and I need to open (load as OGR dataset) all ENC files that are found, in order to check their coverages. Is there a way to check the file coverage without loading the file? (since I'm dealing with around a hunred of them, this operation takes minutes) On Sun, Oct 18, 2009 at 4:49 AM, Frank Warmerdam wrote: > Yilmaz Arslanoglu wrote: >> >> Hello everybody; >> >> I was just wondering whether there is a specific directory structure >> that needs to be followed >> in order to open an S-57 file collection by giving a single directory >> path, instead of a file with a .000 extension. >> >> I'm asking because, according to the following statement from OGR IHO >> S-57 (ENC) Driver >> documentation, we would be able to pass a directory name. >> >>>> An S-57 dataset can be a directory (in which case all S-57 files in the >>>> directory are selected), >>>> an S-57 catalog file (in which case all files referred to from the >>>> catalog are selected) or an individual S-57 data file. > > Yilmaz, > > On review of the code it appears the documentation is wrong and > multiple file access was never fully implemented. I have updated > the documentation accordingly. > >> However, when I try to open with a directory name using >> "OGRSFDriverRegistrar::Open", I get an error. >> >> As another question: >> >>>> S-57 update files contain information on how to update a distributed >>>> S-57 base data file. >>>> The base files normally have the extension .000 while the update files >>>> have extensions like .001, .002 and so on. >>>> The S-57 reader will normally read and apply all updates files to the in >>>> memory version of the base file on the fly. >>>> The feature data provided to the application therefore includes all the >>>> updates. >> >> So how OGR decides to look for the extension files? Because as far as >> I can see, ENC catalogues may come >> with different directory structures, where in some of them all update >> files accompany the original one in the same directory, >> however they may also come in another directory in some others. > > The driver will only find update files if they are in the same directory > as the .000 file, have names like .001, etc and a shared basename. > > 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 > > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDAL with MFC
Hi all;
Using the GDAL/OGR library, I made a module which extracts the depth points
from the sounding and contour layers of an ENC file.
Everything works perfect if this module is used in a non-MFC project
(btw, projects are compiled with VS 2008) However, when the module is moved
to an MFC-based project, sounding point values (x, y, and z) come as abnormal
values, whereas no problem occurs with the values that come from the
contour layer.
I know that this can possibly originate from different heaps (GDAL dll vs. MFC),
however I wrote the code so that all pointers are created, handled, and finally
destroyed by the GDAL library. Should I not expect a possible heap
corruption problem
here ?
Here, first I insert all features in a vector:
OGRFeature *poFeature = NULL;
m_poLayerRef = poDS->GetLayerByName( "SOUNDG" );
m_poLayerRef->ResetReading();
std::vector m_features;
while( (poFeature = m_poLayerRef->GetNextFeature() ) != NULL )
{
OGRGeometry *poGeometry = poFeature->GetGeometryRef();
assert( poGeometry != NULL );
if ( poGeometry != NULL )
{
if ( wkbFlatten(poGeometry->getGeometryType()) == wkbPoint)
{
m_features.push_back(poFeature);
}
else
OGRFeature::DestroyFeature(poFeature);
}
else
OGRFeature::DestroyFeature(poFeature);
}
Then, I insert all the points to another structure as follows:
for (std::vector::iterator it = m_features.begin(); it
!= m_features.end(); it++)
{
poFeature = (*it);
poGeometry = poFeature->GetGeometryRef();
assert( (poGeometry != NULL) && (
wkbFlatten(poGeometry->getGeometryType()) == wkbPoint ) );
if ( (poGeometry != NULL) && (
wkbFlatten(poGeometry->getGeometryType()) == wkbPoint ) )
{
x = ( ((OGRPoint *)poGeometry)->getX() );
y = ( ((OGRPoint *)poGeometry)->getY() );
z = ( ((OGRPoint *)poGeometry)->getZ() );
depthMap.Insert( x, y, z );
}
}
As another question, I do the following simple operation (again in MFC):
OGRSpatialReference *poSRS = new OGRSpatialReference;
OGRSpatialReference::DestroySpatialReference(poSRS);
and I get heap corruption error. Do we have another way to create a
spatial reference system object for this purpose?
Best regards,
Yilmaz
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDALFillNodata link error
Hi all; In version 1.6.2 and 1.6.3, the usage of the function "GDALFillNodata" gives a linker error, since "rasterfill.obj" is not listed under OBJ in "Makefile.vc" under "gdal\alg". However, it is listed in the current development version ( 1.7 ) Does this mean that the function GDALFillNodata is not intended to be used before 1.7 ? As another question, is there a way to access somehow the iso8211 functionality ( DDFModule etc. ) via gdal library, or do we need to compile it as a seperate dll ? I tried to build the makefile under "gdal\frmts\iso8211" with "iso8211.dll" option, but it gives linker errors with this option as follows: Creating library iso8211_i.lib and object iso8211_i.exp cpl.lib(cpl_vsil_gzip.obj) : error LNK2019: unresolved external symbol _inflateEnd referenced in function "public: virtual __thiscall VSIGZipHandle::~VSIGZipHandle(void)" (??1VSIGZipHandle@@u...@xz) cpl.lib(cpl_minizip_unzip.obj) : error LNK2001: unresolved external symbol _inflateEnd cpl.lib(cpl_vsil_gzip.obj) : error LNK2019: unresolved external symbol _inflateReset referenced in function "private: int __thiscall VSIGZipHandle::gzrewind(void)" (?gzrew...@vsigziphandle@@AAEHXZ) cpl.lib(cpl_vsil_gzip.obj) : error LNK2019: unresolved external symbol _crc32 referenced in function "private: int __thiscall VSIGZipHandle::gzrewind(void)" (?gzrew...@vsigziphandle@@AAEHXZ) cpl.lib(cpl_minizip_unzip.obj) : error LNK2001: unresolved external symbol _crc32 cpl.lib(cpl_vsil_gzip.obj) : error LNK2019: unresolved external symbol _inflateCopy referenced in function "private: int __thiscall VSIGZipHandle::gzseek(unsigned __int64,int)" (?gzs...@vsigziphandle@@aaeh...@z) cpl.lib(cpl_vsil_gzip.obj) : error LNK2019: unresolved external symbol _deflateInit2_ referenced in function "public: __thiscall VSIGZipWriteHandle::VSIGZipWriteHandle(class VSIVirtualHandle *)" (??0VSIGZipWriteHandle@@q...@pavvsivirtualhandle@@@Z) cpl.lib(cpl_vsil_gzip.obj) : error LNK2019: unresolved external symbol _deflateEnd referenced in function "public: virtual int __thiscall VSIGZipWriteHandle::Close(void)" (?cl...@vsigzipwritehandle@@UAEHXZ) cpl.lib(cpl_vsil_gzip.obj) : error LNK2019: unresolved external symbol _deflate referenced in function "public: virtual int __thiscall VSIGZipWriteHandle::Close(void)" (?cl...@vsigzipwritehandle@@UAEHXZ) cpl.lib(cpl_vsil_gzip.obj) : error LNK2019: unresolved external symbol _inflate referenced in function "public: virtual unsigned int __thiscall VSIGZipHandle::Read(void *,unsigned int,unsigned int)" (?r...@vsigziphandle@@uaeipa...@z) cpl.lib(cpl_minizip_unzip.obj) : error LNK2001: unresolved external symbol _inflate cpl.lib(cpl_vsil_gzip.obj) : error LNK2019: unresolved external symbol _inflateInit2_ referenced in function "public: __thiscall VSIGZipHandle::VSIGZipHandle(class VSIVirtualHandle *,char const *,unsigned __int64,unsigned __int64,unsigned __int64,unsigned int,int)" (??0VSIGZipHandle@@q...@pavvsivirtualhandle@@pbd_k2...@z) cpl.lib(cpl_minizip_unzip.obj) : error LNK2001: unresolved external symbol _inflateInit2_ iso8211.dll : fatal error LNK1120: 9 unresolved externals ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDALFillNodata link error
Thank you very much for the answers, Frank. Defining CPL_OPTIONAL_APIS did actually exactly what I want, thanks again... On Mon, Nov 23, 2009 at 7:05 PM, Frank Warmerdam wrote: > Yilmaz Arslanoglu wrote: >> >> Hi all; >> >> In version 1.6.2 and 1.6.3, the usage of the function >> "GDALFillNodata" gives a linker error, since "rasterfill.obj" is not >> listed under OBJ >> in "Makefile.vc" under "gdal\alg". However, it is listed in the >> current development version ( 1.7 ) >> >> Does this mean that the function GDALFillNodata is not intended to be >> used before 1.7 ? > > Yilmaz, > > The fill nodata support was not really fully finished in 1.6, and it > seems it was accidentally omitted from the windows makefile. I see it > is in the unix GNUmakefile. You can try it from 1.6, but you are better > off doing it in the 1.7/trunk tree if you want something dependable. > >> As another question, is there a way to access somehow the iso8211 >> functionality ( DDFModule etc. ) >> via gdal library, or do we need to compile it as a seperate dll ? I >> tried to build the makefile under >> "gdal\frmts\iso8211" with "iso8211.dll" option, but it gives linker >> errors with this option as follows: > > There are a bunch of library interfaces that are considered to be internal > to GDAL and these are generally declared with CPL_ODLL instead of CPL_DLL. > If you add: > > #define CPL_OPTIONAL_APIS 1 > > in gdal/port/cpl_config.h or somewhere else appropriate it should cause > these interfaces to be exported from the GDAL DLL instead of being hidden > as they are by default. I have confirmed this includes the iso8211 > interfaces. > > It would appear the local makefile targets for building a DLL are out of > date and would need some TLC to build standalone. > > 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 > > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] using encrypted data
Hi all; One of our customer wants to share their data which is in ESRI Shapefile format. However, they also would like to limit the usage of this data such that the contents will be utilized only through our software, and not for any other purposes. Does anybody have a suggestion about how this could be achieved ? Does GDAL have any related encryption based support, and is there any GDAL supported encrypted vector formats that we can convert it into? Best regards, Yilmaz ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] using encrypted data
Thank you very much for pointing to the sources, Frank! Let me have a look at them, then... On Wed, Mar 3, 2010 at 3:53 PM, Frank Warmerdam wrote: > Yilmaz Arslanoglu wrote: >> >> Hi all; >> >> One of our customer wants to share their data which is in ESRI Shapefile >> format. >> However, they also would like to limit the usage of this data such >> that the contents >> will be utilized only through our software, and not for any other >> purposes. >> >> Does anybody have a suggestion about how this could be achieved ? >> Does GDAL have any related encryption based support, and is there any >> GDAL supported encrypted vector formats that we can convert it into? > > Yilmaz, > > There are no encrypted GDAL or OGR formats that come to mind. > > My suggestion is that you encrypt the shapefile(s) using some > generic encryption and then implement a VSI*L filesystem handler > for /vsiyilmazencrypt/ that would decrypt the data on the fly as > it is read. > > The VSI*L file access layer provides for library and application > supplied custom file io handlers. There are several examples of > implementations in gdal/port including cpl_vsil_subfile.cpp and > cpl_vsil_mem.cpp and cpl_vsil_unix_stdio_64.cpp. > > I'm sure a good search on encryption libraries will turn up various > options for encryption libraries. > > 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 > > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] using encrypted data
Hi Russell; Yes, you are right, actually we are also considering the option that you have mentioned. Because even the best technical option will be hackable in theory, anyway... On Wed, Mar 3, 2010 at 4:55 PM, Russell McOrmond wrote: > > On Wed, 3 Mar 2010, Yilmaz Arslanoglu wrote: > >> Hi all; >> >> One of our customer wants to share their data which is in ESRI Shapefile >> format. However, they also would like to limit the usage of this data such >> that the contents will be utilized only through our software, and not for >> any other purposes. > > My recommendation is to accomplish this through contractual measures > protected by law rather than technical measures. Attempts to substitute > technology rather than clarify legal relationships tend to fail and cause > more problems than they are worth. > > -- > Russell McOrmond, Internet Consultant: <http://www.flora.ca/> > Please help us tell the Canadian Parliament to protect our property > rights as owners of Information Technology. Sign the petition! > http://digital-copyright.ca/petition/ict/ http://KillBillC61.ca > > "The government, lobbied by legacy copyright holders and hardware > manufacturers, can pry control over my camcorder, computer, > home theatre, or portable media player from my cold dead hands!" > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
