Re: [gdal-dev] [update] Re: Travis CI continuous integration service for GDAL

[Ari Jolma]

On 10/10/2012 10:49 PM, Etienne Tourigny wrote:

Hi Even,


On Wed, Oct 10, 2012 at 4:24 PM, Even Rouault
 wrote:


My feeling is that the main barrier to contribution lies more in understanding
how the source works rather than the tools around.

Anyway, whatever the VCS, as you underlined, you still need competent eyes to
review, comment on, fix by themselves the patch or ask the contributor to do
changes, apply, or reject patches... Trac has already such patches waiting.

I'd also say - if it works don't fix it.  Transitioning to git(hub) is
certainly possible (QGIS managed to get it working well), but it will
entain some productivity loss in the short term.


Just a small, probably very controversial, comment on this issue. If 
something works but you don't understand how or why, then the situation 
is very dangerous. You can get to this situation also when someone 
knowledgeable leaves. I would say that for example the swig part of GDAL 
is very difficult to grasp - there simply are so many moving parts. 
Thus, some development effort should be put into fixing working things.


I once did a test to re-organize (sanitize ;) the swig tree of GDAL - 
this is still in the sandbox. I also don't know enough of Git to know 
whether tests or forks like that would get more exposure or testing, but 
I'm interested in it. There are also some major issues that could be 
tested with GDAL (for example dynamic run-time loading of drivers like 
modules are loaded into Linux kernel, or XYZM support) - if these things 
could be developed and tested better with Git, I'm also interested.


Cheers,

Ari
https://github.com/ajolma

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

Re: [gdal-dev] S57 dataset boundary issue

[s duclos]

Nikhil,



>If I have a polygon how to find out edges of it programmatic do we have any 
>function to get all  the edges of polygon(area)

OGR is modelled on the OpenGIS simple features data model,

http://www.gdal.org/ogr/ogr_arch.html

In this model there is no notion of edge like in S-57

You did use the OGR internal representation using RETURN_LINKAGES=ON
But that is for debugging .. it's not part of OGR official interface as I can 
see.

But RETURN_LINKAGES=ON give you a fighting chance if you need to find edge
and also to will need to hack the source code of OGR as it limit the output to 
80 char.



rgds,

Sylvain.




>
> From: Nikhil Sai Parupalli 
>To: s duclos  
>Cc: "gdal-dev@lists.osgeo.org"  
>Sent: Thursday, October 11, 2012 1:26:47 AM
>Subject: RE: [gdal-dev] S57 dataset boundary issue
> 
>Hey Sylvain,
>
>Thanks for your inputs, we have successfully implemented the same in our 
>project .
>I have one more question i.e 
>If I have a polygon how to find out edges of it programmatic do we have any 
>function to get all  the edges of polygon(area)
>
>
>Thanks and Regards
>Nikhil Sai Parupalli
>
>
>
>Note: Do not print this email until and unless it is really required. Save 
>paper , stay Green
>
>
>From: Nikhil Sai Parupalli
>Sent: Wednesday, October 10, 2012 9:07 PM
>To: s duclos
>Subject: RE: [gdal-dev] S57 dataset boundary issue
>
>Thanks and Regards
>Nikhil Sai Parupalli
>
>
>
>Note: Do not print this email until and unless it is really required. Save 
>paper , stay Green
>
>
>From: s duclos [sylvain_duc...@yahoo.com]
>Sent: Wednesday, October 10, 2012 8:43 PM
>To: Nikhil Sai Parupalli; Frank Warmerdam
>Cc: gdal-dev@lists.osgeo.org
>Subject: Re: [gdal-dev] S57 dataset boundary issue
>
>Hi Nikhil,
>
>> Based on the code which you have sent we could find out CW and CCW, but not
>> outer/inner
>
>The outer ring of OGRGeometryH poly is  the ring 0 (zero).
>
>
>In C code the OGR call:
>
>
>            guint        nRingCount = OGR_G_GetGeometryCount(hGeom);
>
>
>will give you the number of rings in a poly.
>
>Say there is 2 rings for this hGeom. Then the outer ring is
>
>    OGRGeometryH *hGeomRef_outter  = OGR_G_GetGeometryRef(hGeom, 0);
>
>and the inner ring is
>
>    OGRGeometryH *hGeomRef_inner  = OGR_G_GetGeometryRef(hGeom, 1);
>
>
>
>> Please have a look at that data set once and let me know.
>
>
>There is nothing in attachment
>
>
>rgds,
>
>Sylvain.
>
>
>
>- Original Message -
>> From: Nikhil Sai Parupalli 
>> To: s duclos ; Frank Warmerdam 
>> 
>> Cc: "gdal-dev@lists.osgeo.org" 
>> Sent: Wednesday, October 10, 2012 10:40:27 AM
>> Subject: RE: [gdal-dev] S57 dataset boundary issue
>>
>> Hey Sylvain,
>>
>> Thanks for trying the data which I have sent.
>>
>> Could you be helping me how this works like outer boundary and inner 
>> boundary.
>>
>>
>>
>> Based on the code which you have sent we could find out CW and CCW, but not
>> outer/inner
>> Please have a look at that data set once and let me know.
>> Or if you have any sample data with simple representation of outer and inner
>> boundaries please do share with me.
>>
>>
>>
>>
>> Thanks and Regards
>> Nikhil Sai Parupalli
>>
>>
>>
>> Note: Do not print this email until and unless it is really required. Save 
>> paper
>> , stay Green
>>
>> 
>> From: s duclos [sylvain_duc...@yahoo.com]
>> Sent: Wednesday, October 10, 2012 7:59 PM
>> To: Nikhil Sai Parupalli; Frank Warmerdam
>> Cc: gdal-dev@lists.osgeo.org
>> Subject: Re: [gdal-dev] S57 dataset boundary issue
>>
>> Hi Nikhil,
>>
>> I loaded US1GC09M//US1GC09M.000 .. it's huge :)
>>
>> It's the Gulf of Mexico .. now where should I look ?
>>
>>
>>
>> About the inner / outer ring. As I said before, I just assume that OGR
>> send me the outer ring first. And, up to now, my code is working fine.
>>
>>
>> rgds,
>>
>> Sylvain.
>>
>>
>>
>>
>> - Original Message -
>>>  From: Nikhil Sai Parupalli 
>>>  To: s duclos ; Frank Warmerdam
>> 
>>>  Cc: "gdal-dev@lists.osgeo.org" 
>>>  Sent: Wednesday, October 10, 2012 9:40:54 AM
>>>  Subject: RE: [gdal-dev] S57 dataset boundary issue
>>>
>>>  Could you try on this data set please
>>>
>>>  Thanks and Regards
>>>  Nikhil Sai Parupalli
>>>
>>>
>>>
>>>  Note: Do not print this email until and unless it is really required. Save
>> paper
>>>  , stay Green
>>>
>>>  
>>>  From: s duclos [sylvain_duc...@yahoo.com]
>>>  Sent: Wednesday, October 10, 2012 7:02 PM
>>>  To: Nikhil Sai Parupalli; Frank Warmerdam
>>>  Cc: gdal-dev@lists.osgeo.org
>>>  Subject: Re: [gdal-dev] S57 dataset boundary issue
>>>
>>>  Nikhil,
>>>
>>>  I loaded your ENC.
>>>
>>>  I see a number of depth area (DEPARE) and anchor zone area (ACHARE).
>>>
>>>  But no inner ring!
>>>
>>>  Is there an inner rings somewhere I should see?
>>>
>>>
>>>
>>>  rgds,
>>>
>>>  Sylvain.
>>>
>>>
>>>
>>>  - O

Re: [gdal-dev] [update] Re: Travis CI continuous integration service for GDAL

[Etienne Tourigny]

Hi

On Wed, Oct 10, 2012 at 5:55 PM, Even Rouault
 wrote:
> Le mercredi 10 octobre 2012 21:49:49, Etienne Tourigny a écrit :
>> Hi Even,
>>
>> the main advantage of github is that you can manage patches/pull
>> requests more easily, and it's easy for someone to setup a fork with
>> substantial changes, and anyone can pull that fork and try it without
>> much hassle.
>> The other way of doing it with trac/svn is to upload patches to
>> tickets, and then more patches after review etc Which works fine,
>> but a bit clumsy compared to github forks and pull requests.
>
> If someone submits a pull requests, and if that submitted code needs to be
> changed due to what is seen during the review, what is the process ? It is
> certainly nice to be able to merge the history of commits (I often wish that
> submitted patches to Trac would be split into more logical smaller changesets
> to make review easier). But that only makes sense when the history is clean
> (you generally don't care about trial-and-errors intermediate commits that
> would pollute the history of the main repository). I believe that it is
> possible to do that with git ("git rewrite history" leads to http://git-
> scm.com/book/ch6-4.html), but to my non-git specialists eyes, this looks far
> from being obvious. Do you know how QGIS for example deal with that ?

reviewer can either push commits to that repos, or add commits after
pulling the contributor's code.

What you would look for is called "interactive rebasing"

You can "squash" history in a single commit doing git rebase -i
, which will open an editor with the commits since , you
then mark all commits except one as "squash"..
History will then contain a single commit, but it will not let you
push back to the same branch (unless you do a force push, which messes
with the history)

So the sequence would be:

git pull  
git rebase -i 

git push origin master

But this removes the commits from the original authore, so to keep
history you would do

git pull  
git push origin master

>
>>
>> I even did some collaborative work last year in gdal using github as
>> the shared repos, and pushing to svn but that was a bit clumsy (the
>> git-svn part) and I have stopped using that approach.
>
> you mean "git svn dcommit" didn't work as you expected ?

it's a little unwieldy, but seems to work as expected. I was always
nervous to do something wrong - because a svn commit / svn dcommit
cannot be reversed, unlike git commit (until you push),
so I was always doing a dry-run commit, examine the diffs, and then do
a real dcommit.

But it does work, as long as you're careful.  It's just a bit more
involved than working with git or svn alone.

>
>>
>> > But as a SVN committer, my opinion is obviously biased since contributing
>> > is of course more straighforward than for a non-GDAL committer. GIT has
>> > certainly a more egalitarian approach (everyone can commit or fork),
>> > although that someone that hasn't push rights can only send pull
>> > requests to the main repository.
>>
>> I'd say svn is fine for core devs, not optimal for occasional submitters.
>>
>> > My knowledge of GIT is rather limited, but, for a GDAL contributor
>> > without commit (SVN)/push(GIT) rights to the main repository, what
>> > improvements would a full move to GIT would offer with respect to the
>> > current git-svn mirroring ?
>>
>> a more seamless flow between the dev's work and pushes to the main source.
>>
>> As far as I can tell, the git part of your setup is just for the
>> continuous builds right?
>
> Yes mostly, and because it might be more convenient for people prefering GIT
> to do work. This could also be a kind of cheap test bench to assess what
> switching to GIT could bring to GDAL.
>
>> In fact git is used as a read-only, so I
>> don't see how having a git mirror helps contributing code.
>
> Can't people fork the git mirror ? My hope was that a GDAL SVN committer could
> use its own git-svn mirror, that has a origin to OSGeo/gdal, and try to merge
> in it pull requests submitted to OSGeo/gdal, and then git svn dcommit. I
> thought this was possible, but I might be wrong. I'm aware that git-svn would
> be more complicated than a pure GIT repository. But, from the side of
> occasional contributors, would that make a difference in their process ?
>
> I'm trying to understand if the git-svn mirror can bring some factual evidence
> that a switch to GIT would be beneficial.

Now I understand better your intent - you would use the git mirror to
be able to have people work on using git/github, and then svn as the
"central" code base that core devs would commit to.

For occasional contributors, it would probably be easier. For the code
managers / core devs, it means an extra step in merging the code to
svn trunk, and entails learning another (git) versioning tool, as well
as the git/svn bridge.
Although once setup, it's not that hard.

It would certainly be easier, especially in the short-term, to keep
svn and allow to us

Re: [gdal-dev] S57 update (was: (no subject))

[s duclos]

Hi Nikhil,

In the US1GC09M.ZIP you send you can see update as

US1GC09M.000  <-- base cell


US1GC09M.001 - .008   <-- update to base cell



rgds,

Sylvain.



>
> From: Nikhil Sai Parupalli 
>To: "gdal-dev@lists.osgeo.org"  
>Sent: Thursday, October 11, 2012 2:28:40 AM
>Subject: [gdal-dev] (no subject)
> 
>
> 
>Hi All, 
>
>
>How do we get to know which S57 dataset has update sin it..
>
>
>
>
>Thanks and Regards
>Nikhil Sai Parupalli
>
>
>
>Note: Do not print this email until and unless it is really required. Save 
>paper , stay Green
>
>___
>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] Dealing with ogr2ogr and cyrillic TAB files

[Luca Sigfrido Percich]

Hi Tuomas,


Il giorno mer, 10/10/2012 alle 10.17 +, Koivusalo, Tuomas ha
scritto:
> I’m trying to convert bunch of MapInfo TAB files from Russian customer
> to PostGIS using ogr2ogr. Original TAB files are in WindowsCyrillic
> encoding, and they should be somehow be converted to UTF-8. For some
> reason, it seems that ogr2ogr messes up encoding during conversion. If
> I try to convert TAB to Shapefile and from Shapefile to PostGIS end
> result is complete mess. Direct conversion from TAB to PostGIS seems
> to fail due to encoding problems (I have tried to set
> PGCLIENTENCODING, but end result doesn’t seem to change). 

Setting PGCLIENTENCODING has alway worked for me, and both ways (it
applies also to PG => MapInfo conversion).

Make sure you're using the correct encoding specification: have you
tried "WIN866", "WIN1251", "ISO_8859_5"...?

> I have managed to create correct Cyrillic output by running ogr2ogr to
> convert TAB to shape, and then creating SQL from shape and then
> running that SQL through perl-script which fixes the encoding, but as
> this includes two-bit characters to columns it causes all field length
> constraints to break. 

You could convert TAB to MIF, process MIF with iconv, and load the
processed file into postgis. One step less :)

Hope this helps

Sig


 

 
PRIVACY
Le informazioni contenute in questo messaggio sono riservate e confidenziali. 
Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio, 
per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la persona 
a cui il presente messaggio è destinato, La invitiamo ad eliminarlo dal Suo 
Sistema e a distruggere le varie copie o stampe, dandone gentilmente 
comunicazione all’indirizzo mail del mittente. Ogni utilizzo improprio e' 
contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva 
2002/58/CE).

_
 
PRIVACY
Le informazioni contenute in questo messaggio sono riservate e confidenziali. 
Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio, 
per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la persona 
a cui il presente messaggio è destinato, La invitiamo ad eliminarlo dal Suo 
Sistema e a distruggere le varie copie o stampe, dandone gentilmente 
comunicazione all’indirizzo mail del mittente. Ogni utilizzo improprio e' 
contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva 
2002/58/CE).
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GDALGetRasterStatistics() and bApproxOK, bForce

[Radim Blazek]

GDALGetRasterStatistics API doc:
"Returns the minimum, maximum, mean and standard deviation of all
pixel values in this band. If approximate statistics are sufficient,
the bApproxOK flag can be set to true in which case overviews, or a
subset of image tiles may be used in computing the statistics.
If bForce is FALSE results will only be returned if it can be done
quickly (ie. without scanning the data). If bForce is FALSE and
results cannot be returned efficiently, the method will return
CE_Warning but no warning will have been issued. This is a
non-standard use of the CE_Warning return value to indicate "nothing
done"."


My understanding is that if it is called with bApproxOK=false and
bForce=false and exact statistics (from all raster pixels) are not
available/cached, it should return CE_Warning. Instead, it is giving
estimated (from sample) cached statistics and it returns CE_None.

Is it expected? If it is, how can I test if exact statistics (from all
raster pixels) are available/cached (to avoid
GDALComputeRasterStatistics() if not necessary). Also, the meaning of
both params should be probably better described in doc.

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

Re: [gdal-dev] GDALGetRasterStatistics() and bApproxOK, bForce

[Frank Warmerdam]

Radim,

I gather the problem is that GDAL cannot tell whether saved statistics in
metadata are exact or not, right?  I don't have any real plan to resolve
this unfortunately.   I ticket might be prudent.

Best regards,
Frank

On Thu, Oct 11, 2012 at 8:39 AM, Radim Blazek wrote:

> GDALGetRasterStatistics API doc:
> "Returns the minimum, maximum, mean and standard deviation of all
> pixel values in this band. If approximate statistics are sufficient,
> the bApproxOK flag can be set to true in which case overviews, or a
> subset of image tiles may be used in computing the statistics.
> If bForce is FALSE results will only be returned if it can be done
> quickly (ie. without scanning the data). If bForce is FALSE and
> results cannot be returned efficiently, the method will return
> CE_Warning but no warning will have been issued. This is a
> non-standard use of the CE_Warning return value to indicate "nothing
> done"."
>
>
> My understanding is that if it is called with bApproxOK=false and
> bForce=false and exact statistics (from all raster pixels) are not
> available/cached, it should return CE_Warning. Instead, it is giving
> estimated (from sample) cached statistics and it returns CE_None.
>
> Is it expected? If it is, how can I test if exact statistics (from all
> raster pixels) are available/cached (to avoid
> GDALComputeRasterStatistics() if not necessary). Also, the meaning of
> both params should be probably better described in doc.
>
> Radim
> ___
> 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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDALGetRasterStatistics() and bApproxOK, bForce

[Radim Blazek]

On Thu, Oct 11, 2012 at 6:50 PM, Frank Warmerdam  wrote:
> Radim,
>
> I gather the problem is that GDAL cannot tell whether saved statistics in
> metadata are exact or not, right?

It should be possible, at least .aux.html has 1.

In any case, if it is not sure that cached stats are exact, it should
return CE_Warning if bApproxOK=false and bForce=false, I think.

> I don't have any real plan to resolve
> this unfortunately.   I ticket might be prudent.

https://trac.osgeo.org/gdal/ticket/4857

Radim

> Best regards,
> Frank
>
> On Thu, Oct 11, 2012 at 8:39 AM, Radim Blazek 
> wrote:
>>
>> GDALGetRasterStatistics API doc:
>> "Returns the minimum, maximum, mean and standard deviation of all
>> pixel values in this band. If approximate statistics are sufficient,
>> the bApproxOK flag can be set to true in which case overviews, or a
>> subset of image tiles may be used in computing the statistics.
>> If bForce is FALSE results will only be returned if it can be done
>> quickly (ie. without scanning the data). If bForce is FALSE and
>> results cannot be returned efficiently, the method will return
>> CE_Warning but no warning will have been issued. This is a
>> non-standard use of the CE_Warning return value to indicate "nothing
>> done"."
>>
>>
>> My understanding is that if it is called with bApproxOK=false and
>> bForce=false and exact statistics (from all raster pixels) are not
>> available/cached, it should return CE_Warning. Instead, it is giving
>> estimated (from sample) cached statistics and it returns CE_None.
>>
>> Is it expected? If it is, how can I test if exact statistics (from all
>> raster pixels) are available/cached (to avoid
>> GDALComputeRasterStatistics() if not necessary). Also, the meaning of
>> both params should be probably better described in doc.
>>
>> Radim
>> ___
>> 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
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GDAL/OGR 1.9.2 Released

[Frank Warmerdam]

Folks,

I am pleased to announce the release of GDAL/OGR 1.9.2.  This
is a bug fix release based on the GDAL/OGR 1.9.0 (and 1.9.1)
release and does not contain substantial new features.

Detailed bug fix news is available at:
  http://trac.osgeo.org/gdal/wiki/Release/1.9.2-News

Source code is available at:
   http://download.osgeo.org/gdal/gdal192.zip
   http://download.osgeo.org/gdal/gdal-1.9.2.tar.gz

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 Software Developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: Release 1.9.2

[Frank Warmerdam]

Folks,

I declare this motion passed with support from Daniel, Howard, Tamas, Even
and myself.  The release announcement has now been sent out.

Best regards,
Frank

On Tue, Oct 9, 2012 at 12:25 PM, Even Rouault
wrote:

> Le mardi 09 octobre 2012 18:27:29, Frank Warmerdam a écrit :
> > Motion: The GDAL/OGR 1.9.2RC2 release is promoted to be the
> > official GDAL/OGR 1.9.2 release.
> >
> +1 Even
>



-- 
---+--
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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] S57 update (was: (no subject))

[Nikhil Sai Parupalli]

Hey 

HOw do we get to know in data set i.e any attribute information varies for 
update...

Thanks and Regards
Nikhil Sai Parupalli



Note: Do not print this email until and unless it is really required. Save 
paper , stay Green


From: s duclos [sylvain_duc...@yahoo.com]
Sent: Thursday, October 11, 2012 8:55 PM
To: Nikhil Sai Parupalli; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] S57 update (was: (no subject))

Hi Nikhil,

In the US1GC09M.ZIP you send you can see update as

US1GC09M.000  <-- base cell


US1GC09M.001 - .008   <-- update to base cell



rgds,

Sylvain.



>
> From: Nikhil Sai Parupalli 
>To: "gdal-dev@lists.osgeo.org" 
>Sent: Thursday, October 11, 2012 2:28:40 AM
>Subject: [gdal-dev] (no subject)
>
>
>
>Hi All,
>
>
>How do we get to know which S57 dataset has update sin it..
>
>
>
>
>Thanks and Regards
>Nikhil Sai Parupalli
>
>
>
>Note: Do not print this email until and unless it is really required. Save 
>paper , stay Green
>
>___
>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] S57 update (was: (no subject))

[Frank Warmerdam]

Nikhil,

There is no OGR API level way of knowing what S-57 updates are changing.
 They basically get merged into the feature view giving you a "final
result" view through OGR.  If you really need to track this you pretty much
have to open variations on the S-57 datasource with and without the
updates.

If you are just debugging, it is often instructive to run 8211view on the
update files.

Best regards,
Frank

On Thu, Oct 11, 2012 at 11:26 AM, Nikhil Sai Parupalli <
nikhil.parupa...@iictechnologies.com> wrote:

> Hey
>
> HOw do we get to know in data set i.e any attribute information varies for
> update...
>
> Thanks and Regards
> Nikhil Sai Parupalli
>
>
>
> Note: Do not print this email until and unless it is really required. Save
> paper , stay Green
>
> 
> From: s duclos [sylvain_duc...@yahoo.com]
> Sent: Thursday, October 11, 2012 8:55 PM
> To: Nikhil Sai Parupalli; gdal-dev@lists.osgeo.org
> Subject: Re: [gdal-dev] S57 update (was: (no subject))
>
> Hi Nikhil,
>
> In the US1GC09M.ZIP you send you can see update as
>
> US1GC09M.000  <-- base cell
>
>
> US1GC09M.001 - .008   <-- update to base cell
>
>
>
> rgds,
>
> Sylvain.
>
>
>
> >
> > From: Nikhil Sai Parupalli 
> >To: "gdal-dev@lists.osgeo.org" 
> >Sent: Thursday, October 11, 2012 2:28:40 AM
> >Subject: [gdal-dev] (no subject)
> >
> >
> >
> >Hi All,
> >
> >
> >How do we get to know which S57 dataset has update sin it..
> >
> >
> >
> >
> >Thanks and Regards
> >Nikhil Sai Parupalli
> >
> >
> >
> >Note: Do not print this email until and unless it is really required.
> Save paper , stay Green
> >
> >___
> >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
>



-- 
---+--
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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] S57 update (was: (no subject))

[s duclos]

Hi Nikhil,

Frank as put up a page for this
(sorry Frank for highjacking the thread)

 
http://www.gdal.org/ogr/drv_s57.html

Also IHO have the specs for updating ENC specifically.
(I don't have the link right now)



rgds,

Sylvain.



- Original Message -
> From: Nikhil Sai Parupalli 
> To: s duclos 
> Cc: "gdal-dev@lists.osgeo.org" 
> Sent: Thursday, October 11, 2012 2:26:54 PM
> Subject: RE: [gdal-dev] S57 update (was: (no subject))
> 
> Hey 
> 
> HOw do we get to know in data set i.e any attribute information varies for 
> update...
> 
> Thanks and Regards
> Nikhil Sai Parupalli
> 
> 
> 
> Note: Do not print this email until and unless it is really required. Save 
> paper 
> , stay Green
> 
> 
> From: s duclos [sylvain_duc...@yahoo.com]
> Sent: Thursday, October 11, 2012 8:55 PM
> To: Nikhil Sai Parupalli; gdal-dev@lists.osgeo.org
> Subject: Re: [gdal-dev] S57 update (was: (no subject))
> 
> Hi Nikhil,
> 
> In the US1GC09M.ZIP you send you can see update as
> 
> US1GC09M.000  <-- base cell
> 
> 
> US1GC09M.001 - .008   <-- update to base cell
> 
> 
> 
> rgds,
> 
> Sylvain.
> 
> 
> 
>> 
>>  From: Nikhil Sai Parupalli 
>> To: "gdal-dev@lists.osgeo.org" 
>> Sent: Thursday, October 11, 2012 2:28:40 AM
>> Subject: [gdal-dev] (no subject)
>> 
>> 
>> 
>> Hi All,
>> 
>> 
>> How do we get to know which S57 dataset has update sin it..
>> 
>> 
>> 
>> 
>> Thanks and Regards
>> Nikhil Sai Parupalli
>> 
>> 
>> 
>> Note: Do not print this email until and unless it is really required. Save 
> paper , stay Green
>> 
>> ___
>> 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] build error - conflicting cpl_serv.h

[Frank Warmerdam]

Dave,

It seems to relate to my use of CPLString in this restricted file, a change
I luckily didn't backport to 1.9.  I have removed it, and made a note to
myself to avoid this in the future.  I'm sure I've done it before.

Best regards,

On Wed, Oct 10, 2012 at 6:44 PM, David Burken  wrote:

> Hi Everyone,
>
> Just fyi, I can't build gdal with an external libgeotif without doing a
> hack...  Both gdal and libgeotiff from svn trunk.  libtiff, geotiff were
> installed in a fresh sandbox.  Then configured gdal to use external
> libtiff/geotiff.
>
> I got gdal to build by removing the libgeotiff installed cpl_serv.h and
> copying gdal/frmts/gtiff/libgeotiff/**cpl_serv.h  to gdal/port/cpl_serv.h
> (in build include path).  That's a hack I know but fixed.  This was broken
> before and fixed.  Seems like it's back again.
>
> Not an issue for me but I thought I'd report it...  Error from build below.
>
> Take care,
> Dave
>
>
> make[2]: Entering directory `/home/work/test/gdal/frmts/**gtiff'
> /bin/sh /work/test/gdal/libtool --mode=compile --tag=CXX g++ -g -O2 -Wall
>  -I..  -I../jpeg -DHAVE_LIBJPEG -I/work/test/gdal/port
> -I/work/test/gdal/gcore -I/work/test/gdal/alg -I/work/test/gdal/ogr
> -I/work/test/gdal/ogr/ogrsf_**frmts  -DBIGTIFF_SUPPORT -DOGR_ENABLED
> -D_REENTRANT  -I/work/test/gdal/port -I/usr/local/ossim/include
> -I/usr/local/ossim/include  -c -o ../o/gt_wkt_srs.lo gt_wkt_srs.cpp
> libtool: compile:  g++ -g -O2 -Wall -I.. -I../jpeg -DHAVE_LIBJPEG
> -I/work/test/gdal/port -I/work/test/gdal/gcore -I/work/test/gdal/alg
> -I/work/test/gdal/ogr -I/work/test/gdal/ogr/ogrsf_**frmts
> -DBIGTIFF_SUPPORT -DOGR_ENABLED -D_REENTRANT -I/work/test/gdal/port
> -I/usr/local/ossim/include -I/usr/local/ossim/include -c gt_wkt_srs.cpp
>  -fPIC -DPIC -o ../o/.libs/gt_wkt_srs.o
> In file included from /work/test/gdal/port/cpl_port.**h:84,
>  from /work/test/gdal/ogr/ogr_core.**h:33,
>  from /work/test/gdal/ogr/ogr_srs_**api.h:34,
>  from /work/test/gdal/ogr/ogr_**spatialref.h:34,
>  from gt_wkt_srs.cpp:38:
> /work/test/gdal/port/cpl_**config.h:106:1: warning: "HAVE_STDLIB_H"
> redefined
> In file included from /usr/local/ossim/include/cpl_**serv.h:36,
>  from gt_wkt_srs.cpp:33:
> /usr/local/ossim/include/geo_**config.h:5:1: warning: this is the
> location of the previous definition
> In file included from /work/test/gdal/port/cpl_port.**h:84,
>  from /work/test/gdal/ogr/ogr_core.**h:33,
>  from /work/test/gdal/ogr/ogr_srs_**api.h:34,
>  from /work/test/gdal/ogr/ogr_**spatialref.h:34,
>  from gt_wkt_srs.cpp:38:
> /work/test/gdal/port/cpl_**config.h:112:1: warning: "HAVE_STRING_H"
> redefined
> In file included from /usr/local/ossim/include/cpl_**serv.h:36,
>  from gt_wkt_srs.cpp:33:
> /usr/local/ossim/include/geo_**config.h:11:1: warning: this is the
> location of the previous definition
> gt_wkt_srs.cpp: In function 'CPLErr GTIFWktFromMemBuf(int, unsigned char*,
> char**, double*, int*, GDAL_GCP**)':
> gt_wkt_srs.cpp:2331: error: 'CPLString' was not declared in this scope
> gt_wkt_srs.cpp:2331: error: expected ';' before 'osFilename'
> gt_wkt_srs.cpp:2333: error: 'osFilename' was not declared in this scope
> make[2]: *** [../o/gt_wkt_srs.lo] Error 1
> make[2]: Leaving directory `/home/work/test/gdal/frmts/**gtiff'
> make[1]: *** [gtiff-install-obj] Error 2
> make[1]: Leaving directory `/home/work/test/gdal/frmts'
> make: *** [frmts-target] Error 2
>
> __**_
> 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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] [ OGR SQL: Excecuting select where column name starts with "_" SO: Windows 7, GDAL/OGR 1.9.x

[Etienne Tourigny]

try enclosing the column with single or double quotes?

On Tue, Oct 9, 2012 at 5:35 PM, Gabriel Fusca
 wrote:
>
> Hi,
>
> I´m getting a sql parsing error when I tried to execute a query to a
> shapefile where column name starts with "_".
>
> When i execute a query like : ogrinfo Provincias.shp -sql "SELECT * FROM
> Provincias WHERE tipo = 1"
>
> INFO: Open of `Provincias.shp'
>   using driver `ESRI Shapefile' successful.
> Layer name: Provincias
> Geometry: Line String
> Feature Count: 21
> Extent: (309062.03, 3895521.90) - (2039227.59, 7591083.24)
> Layer SRS WKT:
> PROJCS["500K",
> GEOGCS["GCS_WGS_1984",
> DATUM["WGS_1984",
> SPHEROID["WGS_84",6378137.0,298.257223563]],
> PRIMEM["Greenwich",0.0],
> UNIT["Degree",0.017453292519943295]],
> PROJECTION["Transverse_Mercator"],
> PARAMETER["False_Easting",100.0],
> PARAMETER["False_Northing",0.0],
> PARAMETER["Central_Meridian",-64.0],
> PARAMETER["Scale_Factor",1.0],
> PARAMETER["Latitude_Of_Origin",-90.0],
> UNIT["Meter",1.0]]
> ID: String (1.0)
> _tipo_Area: Integer (10.0)
> _desc_Area: String (1.0)
> tipo: Integer (10.0)
> OGRFeature(Provincias):29
>   ID (String) = 0
>   _tipo_Area (Integer) = 1
>   _desc_Area (String) = (null)
>   tipo (Integer) = 1
>   LINESTRING (873405.76 7463549.34,873313.54 7463695.39,872765.09
> 7465104.71,872
> 623.98 7465495.26)
>
> But when i want to execute a query like "SELECT * FROM Provincias WHERE
> _tipoArea = 1"
>
>
>> ogrinfo Provincias.shp -sql "SELECT * FROM
> WHERE _tipo_Area = 1"
> INFO: Open of `Provincias.shp'
>   using driver `ESRI Shapefile' successful.
> ERROR 1: SQL Expression Parsing Error: syntax error
>
>
> Any ideas on how to get around this?
>
> Best regards,
>
> --
> Gabriel Fusca
> SUR Emprendimientos Tecnológicos
>
> Perú 345  Piso 5to Oficina "B" (C1067AAG)
> Ciudad de Buenos Aires, Argentina
> Tel. +54 (11) 4342-2976/84
> gabrielfu...@suremptec.com.ar
> http://www.suremptec.com/
>
>
> ___
> 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] S57 update (was: (no subject))

[Nikhil Sai Parupalli]

Hey ,

This was the check i was referencing to 
For record updates for feature/vector updates, check that if it is
 DELETE: the record does not contain further fields, or
 MODIFY/INSERT: the record contains more information about the update.

Could you understand something about this...


Thanks and Regards
Nikhil Sai Parupalli



Note: Do not print this email until and unless it is really required. Save 
paper , stay Green


From: s duclos [sylvain_duc...@yahoo.com]
Sent: Friday, October 12, 2012 12:19 AM
To: Nikhil Sai Parupalli
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] S57 update (was: (no subject))

Hi Nikhil,

Frank as put up a page for this
(sorry Frank for highjacking the thread)


http://www.gdal.org/ogr/drv_s57.html

Also IHO have the specs for updating ENC specifically.
(I don't have the link right now)



rgds,

Sylvain.



- Original Message -
> From: Nikhil Sai Parupalli 
> To: s duclos 
> Cc: "gdal-dev@lists.osgeo.org" 
> Sent: Thursday, October 11, 2012 2:26:54 PM
> Subject: RE: [gdal-dev] S57 update (was: (no subject))
>
> Hey
>
> HOw do we get to know in data set i.e any attribute information varies for
> update...
>
> Thanks and Regards
> Nikhil Sai Parupalli
>
>
>
> Note: Do not print this email until and unless it is really required. Save 
> paper
> , stay Green
>
> 
> From: s duclos [sylvain_duc...@yahoo.com]
> Sent: Thursday, October 11, 2012 8:55 PM
> To: Nikhil Sai Parupalli; gdal-dev@lists.osgeo.org
> Subject: Re: [gdal-dev] S57 update (was: (no subject))
>
> Hi Nikhil,
>
> In the US1GC09M.ZIP you send you can see update as
>
> US1GC09M.000  <-- base cell
>
>
> US1GC09M.001 - .008   <-- update to base cell
>
>
>
> rgds,
>
> Sylvain.
>
>
>
>> 
>>  From: Nikhil Sai Parupalli 
>> To: "gdal-dev@lists.osgeo.org" 
>> Sent: Thursday, October 11, 2012 2:28:40 AM
>> Subject: [gdal-dev] (no subject)
>>
>>
>>
>> Hi All,
>>
>>
>> How do we get to know which S57 dataset has update sin it..
>>
>>
>>
>>
>> Thanks and Regards
>> Nikhil Sai Parupalli
>>
>>
>>
>> Note: Do not print this email until and unless it is really required. Save
> paper , stay Green
>>
>> ___
>> 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