Re: [gdal-dev] Usage of styles in C API
With Nik available for testing, I can update the style table definition.
On 3 Aug 2014 16:39, "Even Rouault" wrote:
> Le dimanche 03 août 2014 12:55:44, Nik Sands a écrit :
> > Thanks Even,
> >
> > Yes, deleting the spaces seems to get it working correctly. Is this
> > expected? Are spaces an illegal part of a style string?
> >
> > The documentation includes spaces in the example .ofs file there, so I
> had
> > copied that format when creating my text file.
>
> I guess we should be tolerant with spaces. The grammar of the style string
> itself seems to indicate that no spaces are expected in the style_def
> itself.
> But the format of the .ofs file is not really well defined.
>
> Perhaps Chaitanya will take care of that. See previous email.
>
> >
> > Cheers,
> > Nik.
> >
> > On 3 Aug 2014, at 8:45 pm, Even Rouault
> wrote:
> > > Le dimanche 03 août 2014 12:41:56, Nik Sands a écrit :
> > >> Sorry, my mistake... I had my logging in the wrong place. styleChars
> is
> > >>
> > >> actually of the form (including the leading space):
> > >>' PEN(c:#A08080,w:2pt); LABEL(c:#00,s:18pt,t:{title})'
> > >
> > > The issue must be the leading space before PEN, and potentially LABEL
> > > too.
> > >
> > >> On 3 Aug 2014, at 8:35 pm, Nik Sands wrote:
> > >>> On one of the iterations through this code, styleChars is:
> > >>> 'vegetation_low: BRUSH(fc:#A0F0A0); LABEL(c:#004000,s:18pt,t:
> {title})'
> > >>>
> > >>> So perhaps the inclusion of the style name is the problem?
> > >>>
> > >>> This was read into a style table from a text file using
> > >>> 'OGR_STBL_LoadStyleTable()'. I had assumed that a similar format to
> > >>> .ofs was suitable. If this is not the case, how should I read a
> style
> > >>> table from a text file in such a way that I can distinguish the
> various
> > >>> styles by name?
> > >>>
> > >>> In guess my more general question is: What is the correct way to
> read
> > >>> styles from an arbitrary text file into a style table, and then use a
> > >>> style manager to get the various parts/tools?
> > >>>
> > >>> On 3 Aug 2014, at 8:26 pm, Even Rouault <
> even.roua...@mines-paris.org>
> > >
> > > wrote:
> > Le dimanche 03 août 2014 12:11:42, Nik Sands a écrit :
> > > I'm just starting out using the styles features of OGR (using the C
> > > API) but at struggling with a few elements of it.
> > >
> > > My code (copied below) fails to get any OGRStyleToolH. Ie, the
> "if (
> > > tool )" block never gets run, because 'tool' is always NULL at the
> > > point indicated by the comment. But the execution does reach that
> > > point in the code which indicates that the OGRStyleMrgH does in
> fact
> > > include at least one part (tool).
> > >
> > > I'd be grateful if somebody could point out what I'm doing wrong.
> >
> > Nothing strikes me as wrong. A potential explanation is that
> > styleChars doesn't contain a valid OGR Feature Style string.
> > GetPartCount() counts the number of ";" separating style parts, but
> it
> > doens't check that each style part actually begins by a recognized
> > tool name (PEN, BRUSH, SYMBOL, LABEL). OGR_SM_GetPart() does this
> > check however and if it cannot recognize it it returns a NULL tool.
> >
> > > Thanks,
> > > Nik.
> > >
> > >
> > > ---
> > >
> > > const char *styleChars = OGR_STBL_GetNextStyle(table) ) )
> > > NSString *styleName = [NSString
> > >
> > > stringWithUTF8String:OGR_STBL_GetLastStyleName(table)];
> OGRStyleMgrH
> > > styleMgr = OGR_SM_Create(NULL);
> > >
> > > OGR_SM_InitStyleString(styleMgr, styleChars);
> > >
> > >
> > > for ( int i = 0; i < OGR_SM_GetPartCount(styleMgr, NULL);
> i++ )
> > > {
> > >
> > > OGRStyleToolH tool = OGR_SM_GetPart(styleMgr, i,
> NULL);
> > >
> > > if ( tool ) // 'tool' always NULL here
> > > {
> > >
> > > switch ( OGR_ST_GetType(tool) )
> > > {
> > >
> > > case OGRSTCPen:
> > > self.pen = tool;
> > > break;
> > >
> > > case OGRSTCBrush:
> > > self.brush = tool;
> > > break;
> > >
> > > case OGRSTCSymbol:
> > > self.symbol = tool;
> > > break;
> > >
> > > case OGRSTCLabel:
> > > self.label = tool;
> > > break;
> > >
> > >
Re: [gdal-dev] Usage of styles in C API
Le dimanche 03 août 2014 12:55:44, Nik Sands a écrit :
> Thanks Even,
>
> Yes, deleting the spaces seems to get it working correctly. Is this
> expected? Are spaces an illegal part of a style string?
>
> The documentation includes spaces in the example .ofs file there, so I had
> copied that format when creating my text file.
I guess we should be tolerant with spaces. The grammar of the style string
itself seems to indicate that no spaces are expected in the style_def itself.
But the format of the .ofs file is not really well defined.
Perhaps Chaitanya will take care of that. See previous email.
>
> Cheers,
> Nik.
>
> On 3 Aug 2014, at 8:45 pm, Even Rouault
wrote:
> > Le dimanche 03 août 2014 12:41:56, Nik Sands a écrit :
> >> Sorry, my mistake... I had my logging in the wrong place. styleChars is
> >>
> >> actually of the form (including the leading space):
> >>' PEN(c:#A08080,w:2pt); LABEL(c:#00,s:18pt,t:{title})'
> >
> > The issue must be the leading space before PEN, and potentially LABEL
> > too.
> >
> >> On 3 Aug 2014, at 8:35 pm, Nik Sands wrote:
> >>> On one of the iterations through this code, styleChars is:
> >>> 'vegetation_low: BRUSH(fc:#A0F0A0); LABEL(c:#004000,s:18pt,t:
{title})'
> >>>
> >>> So perhaps the inclusion of the style name is the problem?
> >>>
> >>> This was read into a style table from a text file using
> >>> 'OGR_STBL_LoadStyleTable()'. I had assumed that a similar format to
> >>> .ofs was suitable. If this is not the case, how should I read a style
> >>> table from a text file in such a way that I can distinguish the various
> >>> styles by name?
> >>>
> >>> In guess my more general question is: What is the correct way to read
> >>> styles from an arbitrary text file into a style table, and then use a
> >>> style manager to get the various parts/tools?
> >>>
> >>> On 3 Aug 2014, at 8:26 pm, Even Rouault
> >
> > wrote:
> Le dimanche 03 août 2014 12:11:42, Nik Sands a écrit :
> > I'm just starting out using the styles features of OGR (using the C
> > API) but at struggling with a few elements of it.
> >
> > My code (copied below) fails to get any OGRStyleToolH. Ie, the "if (
> > tool )" block never gets run, because 'tool' is always NULL at the
> > point indicated by the comment. But the execution does reach that
> > point in the code which indicates that the OGRStyleMrgH does in fact
> > include at least one part (tool).
> >
> > I'd be grateful if somebody could point out what I'm doing wrong.
>
> Nothing strikes me as wrong. A potential explanation is that
> styleChars doesn't contain a valid OGR Feature Style string.
> GetPartCount() counts the number of ";" separating style parts, but it
> doens't check that each style part actually begins by a recognized
> tool name (PEN, BRUSH, SYMBOL, LABEL). OGR_SM_GetPart() does this
> check however and if it cannot recognize it it returns a NULL tool.
>
> > Thanks,
> > Nik.
> >
> >
> > ---
> >
> > const char *styleChars = OGR_STBL_GetNextStyle(table) ) )
> > NSString *styleName = [NSString
> >
> > stringWithUTF8String:OGR_STBL_GetLastStyleName(table)]; OGRStyleMgrH
> > styleMgr = OGR_SM_Create(NULL);
> >
> > OGR_SM_InitStyleString(styleMgr, styleChars);
> >
> >
> > for ( int i = 0; i < OGR_SM_GetPartCount(styleMgr, NULL); i++ )
> > {
> >
> > OGRStyleToolH tool = OGR_SM_GetPart(styleMgr, i, NULL);
> >
> > if ( tool ) // 'tool' always NULL here
> > {
> >
> > switch ( OGR_ST_GetType(tool) )
> > {
> >
> > case OGRSTCPen:
> > self.pen = tool;
> > break;
> >
> > case OGRSTCBrush:
> > self.brush = tool;
> > break;
> >
> > case OGRSTCSymbol:
> > self.symbol = tool;
> > break;
> >
> > case OGRSTCLabel:
> > self.label = tool;
> > break;
> >
> > default:
> > NSLog(@"Unknown style tool
> > type!");
> >
Re: [gdal-dev] Usage of styles in C API
Le dimanche 03 août 2014 12:53:00, Chaitanya kumar CH a écrit :
> I'll add these checks to the method that reads the ofs file. Ticket #5602
You mean a check to reject those lines or to accept them and ignore the
leading spaces ?
Make sure to extend autotest/ogr/ogr_style.py that I had initiated when
mapping the OGR_STBL_ methods to SWIG.
>
> On 3 Aug 2014 16:15, "Even Rouault" wrote:
> > Le dimanche 03 août 2014 12:41:56, Nik Sands a écrit :
> > > Sorry, my mistake... I had my logging in the wrong place. styleChars
> > > is
> > >
> > > actually of the form (including the leading space):
> > > ' PEN(c:#A08080,w:2pt); LABEL(c:#00,s:18pt,t:{title})'
> >
> > The issue must be the leading space before PEN, and potentially LABEL
> > too.
> >
> > > On 3 Aug 2014, at 8:35 pm, Nik Sands wrote:
> > > > On one of the iterations through this code, styleChars is:
> > > > 'vegetation_low: BRUSH(fc:#A0F0A0);
> >
> > LABEL(c:#004000,s:18pt,t:{title})'
> >
> > > > So perhaps the inclusion of the style name is the problem?
> > > >
> > > > This was read into a style table from a text file using
> > > > 'OGR_STBL_LoadStyleTable()'. I had assumed that a similar format to
> > > > .ofs was suitable. If this is not the case, how should I read a
> > > > style table from a text file in such a way that I can distinguish
> > > > the various styles by name?
> > > >
> > > > In guess my more general question is: What is the correct way to
> > > > read styles from an arbitrary text file into a style table, and then
> > > > use a style manager to get the various parts/tools?
> > > >
> > > > On 3 Aug 2014, at 8:26 pm, Even Rouault
> > > >
> >
> > wrote:
> > > >> Le dimanche 03 août 2014 12:11:42, Nik Sands a écrit :
> > > >>> I'm just starting out using the styles features of OGR (using the C
> > > >>> API) but at struggling with a few elements of it.
> > > >>>
> > > >>> My code (copied below) fails to get any OGRStyleToolH. Ie, the "if
> > > >>> ( tool )" block never gets run, because 'tool' is always NULL at
> > > >>> the point indicated by the comment. But the execution does reach
> > > >>> that point in the code which indicates that the OGRStyleMrgH does
> > > >>> in fact include at least one part (tool).
> > > >>>
> > > >>> I'd be grateful if somebody could point out what I'm doing wrong.
> > > >>
> > > >> Nothing strikes me as wrong. A potential explanation is that
> >
> > styleChars
> >
> > > >> doesn't contain a valid OGR Feature Style string.
> > > >> GetPartCount() counts the number of ";" separating style parts, but
> > > >> it doens't check that each style part actually begins by a
> > > >> recognized
> >
> > tool
> >
> > > >> name (PEN, BRUSH, SYMBOL, LABEL). OGR_SM_GetPart() does this check
> > > >> however and if it cannot recognize it it returns a NULL tool.
> > > >>
> > > >>> Thanks,
> > > >>> Nik.
> > > >>>
> > > >>>
> > > >>> ---
> > > >>>
> > > >>> const char *styleChars = OGR_STBL_GetNextStyle(table) ) )
> > > >>> NSString *styleName = [NSString
> > > >>>
> > > >>> stringWithUTF8String:OGR_STBL_GetLastStyleName(table)];
> > > >>> OGRStyleMgrH styleMgr = OGR_SM_Create(NULL);
> > > >>>
> > > >>> OGR_SM_InitStyleString(styleMgr, styleChars);
> > > >>>
> > > >>>
> > > >>> for ( int i = 0; i < OGR_SM_GetPartCount(styleMgr, NULL); i++ )
> > > >>> {
> > > >>>
> > > >>> OGRStyleToolH tool = OGR_SM_GetPart(styleMgr, i, NULL);
> > > >>>
> > > >>> if ( tool ) // 'tool' always NULL here
> > > >>> {
> > > >>>
> > > >>> switch ( OGR_ST_GetType(tool) )
> > > >>> {
> > > >>>
> > > >>> case OGRSTCPen:
> > > >>> self.pen = tool;
> > > >>> break;
> > > >>>
> > > >>> case OGRSTCBrush:
> > > >>> self.brush = tool;
> > > >>> break;
> > > >>>
> > > >>> case OGRSTCSymbol:
> > > >>> self.symbol = tool;
> > > >>> break;
> > > >>>
> > > >>> case OGRSTCLabel:
> > > >>> self.label = tool;
> > > >>> break;
> > > >>>
> > > >>> default:
> > > >>> NSLog(@"Unknown style tool
> > > >>> type!"); break;
> > > >>>
> > > >>> }
> > > >>>
> > > >>> }
> > > >>>
> > > >>> }
> > > >>>
> > > >>> ---
> > > >>>
> > > >>>
> > > >>> ___
>
Re: [gdal-dev] Usage of styles in C API
Thanks Even,
Yes, deleting the spaces seems to get it working correctly. Is this expected?
Are spaces an illegal part of a style string?
The documentation includes spaces in the example .ofs file there, so I had
copied that format when creating my text file.
Cheers,
Nik.
On 3 Aug 2014, at 8:45 pm, Even Rouault wrote:
> Le dimanche 03 août 2014 12:41:56, Nik Sands a écrit :
>> Sorry, my mistake... I had my logging in the wrong place. styleChars is
>> actually of the form (including the leading space):
>>
>> ' PEN(c:#A08080,w:2pt); LABEL(c:#00,s:18pt,t:{title})'
>
> The issue must be the leading space before PEN, and potentially LABEL too.
>
>>
>> On 3 Aug 2014, at 8:35 pm, Nik Sands wrote:
>>> On one of the iterations through this code, styleChars is:
>>> 'vegetation_low: BRUSH(fc:#A0F0A0); LABEL(c:#004000,s:18pt,t:{title})'
>>>
>>> So perhaps the inclusion of the style name is the problem?
>>>
>>> This was read into a style table from a text file using
>>> 'OGR_STBL_LoadStyleTable()'. I had assumed that a similar format to
>>> .ofs was suitable. If this is not the case, how should I read a style
>>> table from a text file in such a way that I can distinguish the various
>>> styles by name?
>>>
>>> In guess my more general question is: What is the correct way to read
>>> styles from an arbitrary text file into a style table, and then use a
>>> style manager to get the various parts/tools?
>>>
>>> On 3 Aug 2014, at 8:26 pm, Even Rouault
> wrote:
Le dimanche 03 août 2014 12:11:42, Nik Sands a écrit :
> I'm just starting out using the styles features of OGR (using the C
> API) but at struggling with a few elements of it.
>
> My code (copied below) fails to get any OGRStyleToolH. Ie, the "if (
> tool )" block never gets run, because 'tool' is always NULL at the
> point indicated by the comment. But the execution does reach that
> point in the code which indicates that the OGRStyleMrgH does in fact
> include at least one part (tool).
>
> I'd be grateful if somebody could point out what I'm doing wrong.
Nothing strikes me as wrong. A potential explanation is that styleChars
doesn't contain a valid OGR Feature Style string.
GetPartCount() counts the number of ";" separating style parts, but it
doens't check that each style part actually begins by a recognized tool
name (PEN, BRUSH, SYMBOL, LABEL). OGR_SM_GetPart() does this check
however and if it cannot recognize it it returns a NULL tool.
> Thanks,
> Nik.
>
>
> ---
>
> const char *styleChars = OGR_STBL_GetNextStyle(table) ) )
> NSString *styleName = [NSString
>
> stringWithUTF8String:OGR_STBL_GetLastStyleName(table)]; OGRStyleMgrH
> styleMgr = OGR_SM_Create(NULL);
>
> OGR_SM_InitStyleString(styleMgr, styleChars);
>
>
> for ( int i = 0; i < OGR_SM_GetPartCount(styleMgr, NULL); i++ )
> {
>
> OGRStyleToolH tool = OGR_SM_GetPart(styleMgr, i, NULL);
>
> if ( tool ) // 'tool' always NULL here
> {
>
> switch ( OGR_ST_GetType(tool) )
> {
>
> case OGRSTCPen:
> self.pen = tool;
> break;
>
> case OGRSTCBrush:
> self.brush = tool;
> break;
>
> case OGRSTCSymbol:
> self.symbol = tool;
> break;
>
> case OGRSTCLabel:
> self.label = tool;
> break;
>
> default:
> NSLog(@"Unknown style tool type!");
> break;
>
> }
>
> }
>
> }
>
> ---
>
>
> ___
> 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
>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Usage of styles in C API
Le dimanche 03 août 2014 12:41:56, Nik Sands a écrit :
> Sorry, my mistake... I had my logging in the wrong place. styleChars is
> actually of the form (including the leading space):
>
> ' PEN(c:#A08080,w:2pt); LABEL(c:#00,s:18pt,t:{title})'
The issue must be the leading space before PEN, and potentially LABEL too.
>
> On 3 Aug 2014, at 8:35 pm, Nik Sands wrote:
> > On one of the iterations through this code, styleChars is:
> > 'vegetation_low: BRUSH(fc:#A0F0A0); LABEL(c:#004000,s:18pt,t:{title})'
> >
> > So perhaps the inclusion of the style name is the problem?
> >
> > This was read into a style table from a text file using
> > 'OGR_STBL_LoadStyleTable()'. I had assumed that a similar format to
> > .ofs was suitable. If this is not the case, how should I read a style
> > table from a text file in such a way that I can distinguish the various
> > styles by name?
> >
> > In guess my more general question is: What is the correct way to read
> > styles from an arbitrary text file into a style table, and then use a
> > style manager to get the various parts/tools?
> >
> > On 3 Aug 2014, at 8:26 pm, Even Rouault
wrote:
> >> Le dimanche 03 août 2014 12:11:42, Nik Sands a écrit :
> >>> I'm just starting out using the styles features of OGR (using the C
> >>> API) but at struggling with a few elements of it.
> >>>
> >>> My code (copied below) fails to get any OGRStyleToolH. Ie, the "if (
> >>> tool )" block never gets run, because 'tool' is always NULL at the
> >>> point indicated by the comment. But the execution does reach that
> >>> point in the code which indicates that the OGRStyleMrgH does in fact
> >>> include at least one part (tool).
> >>>
> >>> I'd be grateful if somebody could point out what I'm doing wrong.
> >>
> >> Nothing strikes me as wrong. A potential explanation is that styleChars
> >> doesn't contain a valid OGR Feature Style string.
> >> GetPartCount() counts the number of ";" separating style parts, but it
> >> doens't check that each style part actually begins by a recognized tool
> >> name (PEN, BRUSH, SYMBOL, LABEL). OGR_SM_GetPart() does this check
> >> however and if it cannot recognize it it returns a NULL tool.
> >>
> >>> Thanks,
> >>> Nik.
> >>>
> >>>
> >>> ---
> >>>
> >>> const char *styleChars = OGR_STBL_GetNextStyle(table) ) )
> >>> NSString *styleName = [NSString
> >>>
> >>> stringWithUTF8String:OGR_STBL_GetLastStyleName(table)]; OGRStyleMgrH
> >>> styleMgr = OGR_SM_Create(NULL);
> >>>
> >>> OGR_SM_InitStyleString(styleMgr, styleChars);
> >>>
> >>>
> >>> for ( int i = 0; i < OGR_SM_GetPartCount(styleMgr, NULL); i++ )
> >>> {
> >>>
> >>> OGRStyleToolH tool = OGR_SM_GetPart(styleMgr, i, NULL);
> >>>
> >>> if ( tool ) // 'tool' always NULL here
> >>> {
> >>>
> >>> switch ( OGR_ST_GetType(tool) )
> >>> {
> >>>
> >>> case OGRSTCPen:
> >>> self.pen = tool;
> >>> break;
> >>>
> >>> case OGRSTCBrush:
> >>> self.brush = tool;
> >>> break;
> >>>
> >>> case OGRSTCSymbol:
> >>> self.symbol = tool;
> >>> break;
> >>>
> >>> case OGRSTCLabel:
> >>> self.label = tool;
> >>> break;
> >>>
> >>> default:
> >>> NSLog(@"Unknown style tool type!");
> >>> break;
> >>>
> >>> }
> >>>
> >>> }
> >>>
> >>> }
> >>>
> >>> ---
> >>>
> >>>
> >>> ___
> >>> 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
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Usage of styles in C API
Sorry, my mistake... I had my logging in the wrong place. styleChars is
actually of the form (including the leading space):
' PEN(c:#A08080,w:2pt); LABEL(c:#00,s:18pt,t:{title})'
On 3 Aug 2014, at 8:35 pm, Nik Sands wrote:
> On one of the iterations through this code, styleChars is:
>
> 'vegetation_low: BRUSH(fc:#A0F0A0); LABEL(c:#004000,s:18pt,t:{title})'
>
> So perhaps the inclusion of the style name is the problem?
>
> This was read into a style table from a text file using
> 'OGR_STBL_LoadStyleTable()'. I had assumed that a similar format to .ofs was
> suitable. If this is not the case, how should I read a style table from a
> text file in such a way that I can distinguish the various styles by name?
>
> In guess my more general question is: What is the correct way to read styles
> from an arbitrary text file into a style table, and then use a style manager
> to get the various parts/tools?
>
>
>
> On 3 Aug 2014, at 8:26 pm, Even Rouault wrote:
>
>> Le dimanche 03 août 2014 12:11:42, Nik Sands a écrit :
>>> I'm just starting out using the styles features of OGR (using the C API)
>>> but at struggling with a few elements of it.
>>>
>>> My code (copied below) fails to get any OGRStyleToolH. Ie, the "if ( tool
>>> )" block never gets run, because 'tool' is always NULL at the point
>>> indicated by the comment. But the execution does reach that point in the
>>> code which indicates that the OGRStyleMrgH does in fact include at least
>>> one part (tool).
>>>
>>> I'd be grateful if somebody could point out what I'm doing wrong.
>>
>> Nothing strikes me as wrong. A potential explanation is that styleChars
>> doesn't contain a valid OGR Feature Style string.
>> GetPartCount() counts the number of ";" separating style parts, but it
>> doens't
>> check that each style part actually begins by a recognized tool name (PEN,
>> BRUSH, SYMBOL, LABEL). OGR_SM_GetPart() does this check however and if it
>> cannot recognize it it returns a NULL tool.
>>
>>>
>>> Thanks,
>>> Nik.
>>>
>>>
>>> ---
>>> const char *styleChars = OGR_STBL_GetNextStyle(table) ) )
>>> NSString *styleName = [NSString
>>> stringWithUTF8String:OGR_STBL_GetLastStyleName(table)]; OGRStyleMgrH
>>> styleMgr = OGR_SM_Create(NULL);
>>> OGR_SM_InitStyleString(styleMgr, styleChars);
>>>
>>>
>>> for ( int i = 0; i < OGR_SM_GetPartCount(styleMgr, NULL); i++ )
>>> {
>>> OGRStyleToolH tool = OGR_SM_GetPart(styleMgr, i, NULL);
>>>
>>> if ( tool ) // 'tool' always NULL here
>>> {
>>> switch ( OGR_ST_GetType(tool) )
>>> {
>>> case OGRSTCPen:
>>> self.pen = tool;
>>> break;
>>>
>>> case OGRSTCBrush:
>>> self.brush = tool;
>>> break;
>>>
>>> case OGRSTCSymbol:
>>> self.symbol = tool;
>>> break;
>>>
>>> case OGRSTCLabel:
>>> self.label = tool;
>>> break;
>>>
>>> default:
>>> NSLog(@"Unknown style tool type!");
>>> break;
>>> }
>>> }
>>> }
>>> ---
>>>
>>>
>>> ___
>>> gdal-dev mailing list
>>> gdal-dev@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>> --
>> 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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Usage of styles in C API
On one of the iterations through this code, styleChars is:
'vegetation_low: BRUSH(fc:#A0F0A0); LABEL(c:#004000,s:18pt,t:{title})'
So perhaps the inclusion of the style name is the problem?
This was read into a style table from a text file using
'OGR_STBL_LoadStyleTable()'. I had assumed that a similar format to .ofs was
suitable. If this is not the case, how should I read a style table from a text
file in such a way that I can distinguish the various styles by name?
In guess my more general question is: What is the correct way to read styles
from an arbitrary text file into a style table, and then use a style manager to
get the various parts/tools?
On 3 Aug 2014, at 8:26 pm, Even Rouault wrote:
> Le dimanche 03 août 2014 12:11:42, Nik Sands a écrit :
>> I'm just starting out using the styles features of OGR (using the C API)
>> but at struggling with a few elements of it.
>>
>> My code (copied below) fails to get any OGRStyleToolH. Ie, the "if ( tool
>> )" block never gets run, because 'tool' is always NULL at the point
>> indicated by the comment. But the execution does reach that point in the
>> code which indicates that the OGRStyleMrgH does in fact include at least
>> one part (tool).
>>
>> I'd be grateful if somebody could point out what I'm doing wrong.
>
> Nothing strikes me as wrong. A potential explanation is that styleChars
> doesn't contain a valid OGR Feature Style string.
> GetPartCount() counts the number of ";" separating style parts, but it
> doens't
> check that each style part actually begins by a recognized tool name (PEN,
> BRUSH, SYMBOL, LABEL). OGR_SM_GetPart() does this check however and if it
> cannot recognize it it returns a NULL tool.
>
>>
>> Thanks,
>> Nik.
>>
>>
>> ---
>> const char *styleChars = OGR_STBL_GetNextStyle(table) ) )
>> NSString *styleName = [NSString
>> stringWithUTF8String:OGR_STBL_GetLastStyleName(table)]; OGRStyleMgrH
>> styleMgr = OGR_SM_Create(NULL);
>> OGR_SM_InitStyleString(styleMgr, styleChars);
>>
>>
>> for ( int i = 0; i < OGR_SM_GetPartCount(styleMgr, NULL); i++ )
>> {
>> OGRStyleToolH tool = OGR_SM_GetPart(styleMgr, i, NULL);
>>
>> if ( tool ) // 'tool' always NULL here
>> {
>> switch ( OGR_ST_GetType(tool) )
>> {
>> case OGRSTCPen:
>> self.pen = tool;
>> break;
>>
>> case OGRSTCBrush:
>> self.brush = tool;
>> break;
>>
>> case OGRSTCSymbol:
>> self.symbol = tool;
>> break;
>>
>> case OGRSTCLabel:
>> self.label = tool;
>> break;
>>
>> default:
>> NSLog(@"Unknown style tool type!");
>> break;
>> }
>> }
>> }
>> ---
>>
>>
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Need some info on geotiff tags missing
Le dimanche 03 août 2014 12:24:29, Andrea Peri a écrit : > thx Even for explanation. > > Also I see the real important for some software is the presence of this > section: > > Keyed_Information: >GTRasterTypeGeoKey (Short,1): RasterPixelIsPoint >End_Of_Keys. > > It can have two possibl values: > RasterPixelIsPoint or RasterPixelIsArea > > Seem that without a value for GTRasterTypeGeoKey some software don't work. > > Is possible configure gdal to add this values when converting a > tif+tfw to a geotiff Andrea, If you try what I suggested ( adding -a_srs "LOCAL_CS[\"Unknown\"]" to gdal_translate command line), you will get : $ listgeo out.tif Geotiff_Information: Version: 1 Key_Revision: 1.0 Tagged_Information: ModelTiepointTag (2,3): [ something ] ModelPixelScaleTag (1,3): [ something ] End_Of_Tags. Keyed_Information: GTRasterTypeGeoKey (Short,1): RasterPixelIsArea GTCitationGeoKey (Ascii,8): "Unknown" GeogAngularUnitsGeoKey (Short,1): Angular_Degree ProjLinearUnitsGeoKey (Short,1): Linear_Meter End_Of_Keys. End_Of_Geotiff. Projection Linear Units: 9001/metre (1.00m) Corner Coordinates: [ something ] You can control RasterPixelIsPoint or RasterPixelIsArea by adding "-mo AREA_OR_POINT=Area" or "-mo AREA_OR_POINT=Point" to the gdal_translate command line. The default is Area. Even > > ? > > Andrea. > > 2014-08-03 10:49 GMT+02:00 Even Rouault : > > Le samedi 02 août 2014 23:48:54, Andrea Peri a écrit : > >> Hi, > >> > >> I have transform many old tiff+tfw rasters using this gdal > >> transformation: > >> > >> gdal_translate -ot Byte -of GTiff -b 1 -a_nodata none -stats -co > >> COMPRESS=NONE -co INTERLEAVE=PIXEL -co PROFILE=GDALGeoTIFF -co > >> TILED=YES -co BLOCKXSIZE=256 -co BLOCKYSIZE=256 -co SPARSE_OK=TRUE -co > >> TFW=NO filein.tif fileout.tif > >> > >> They are wrking correctly with qgis and with mapserver for several > >> months. > >> > >> Now I need to use this geotiffs with another program. > >> But this program say that these images are not realy GeoTiffs. > >> > >> I test them using listgeos and have this result: > >> > >> TIFFReadDirectory: Warning, Unknown field with tag 42112 (0xa480) > >> > >> encountered. Geotiff_Information: > >>Version: 1 > >>Key_Revision: 1.0 > >> > >>Tagged_Information: > >> ModelTiepointTag (2,3): > >> 000 > >> 559417.4456374927786.430528 0 > >> > >> ModelPixelScaleTag (1,3): > >> 0.5 0.5 0 > >> > >> End_Of_Tags. > >> > >>Keyed_Information: > >> End_Of_Keys. > >> > >>End_Of_Geotiff. > >> > >> Some people say me that this is not a true geotiff because are missing > >> several tags. > >> I reported a supposed response from a real geotiff: > >> > >> Geotiff_Information: > >> Version: 1 > >> Key_Revision: 1.0 > >> > >> Tagged_Information: > >>ModelTiepointTag (2,3): > >> 0 0 0 > >> 6733474298291 0 > >> > >>ModelPixelScaleTag (1,3): > >> 1 1 1 > >> > >>End_Of_Tags. > >> > >> Keyed_Information: > >>GTModelTypeGeoKey (Short,1): ModelTypeProjected > >>GTRasterTypeGeoKey (Short,1): RasterPixelIsArea > >>GTCitationGeoKey (Ascii,37): "NAIP 2012 > >> > >> m_3808409_sw_16_1_20120607" > >> > >>ProjectedCSTypeGeoKey (Short,1): PCS_NAD83_UTM_zone_16N > >>PCSCitationGeoKey (Ascii,21): "NAD83 / UTM zone 16N" > >>ProjLinearUnitsGeoKey (Short,1): Linear_Meter > >>End_Of_Keys. > >> > >> End_Of_Geotiff. > >> > >> PCS = 26916 (NAD83 / UTM zone 16N) > >> Projection = 16016 (UTM zone 16N) > >> Projection Method: CT_TransverseMercator > >> > >> ProjNatOriginLatGeoKey: 0.00 ( 0d 0' 0.00"N) > >> ProjNatOriginLongGeoKey: -87.00 ( 87d 0' 0.00"W) > >> ProjScaleAtNatOriginGeoKey: 0.999600 > >> ProjFalseEastingGeoKey: 50.00 m > >> ProjFalseNorthingGeoKey: 0.00 m > >> > >> GCS: 4269/NAD83 > >> Datum: 6269/North American Datum 1983 > >> Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31) > >> Prime Meridian: 8901/Greenwich (0.00/ 0d 0' 0.00"E) > >> Projection Linear Units: 9001/metre (1.00m) > >> > >> Corner Coordinates: > >> Upper Left( 673347.000, 4298291.000) ( 85d 0'12.06"W, > >> 38d48'58.87"N) > >> Lower Left( 673347.000, 4290632.000) ( 85d 0'18.99"W, > >> 38d44'50.54"N) > >> Upper Right ( 679532.000, 4298291.000) ( 84d55'55.75"W, > >> 38d48'54.41"N) > >> Lower Right ( 679532.000, 4290632.000) ( 84d56' 2.92"W, > >> 38d44'46.10"N) > >> Center( 676439.500, 4294461.500) ( 84d58' 7.43"W, > >> 38d46'52.50"N) > >> > >> - > >> > >> I'm a bit confused. > >> Bec
Re: [gdal-dev] Usage of styles in C API
Le dimanche 03 août 2014 12:11:42, Nik Sands a écrit :
> I'm just starting out using the styles features of OGR (using the C API)
> but at struggling with a few elements of it.
>
> My code (copied below) fails to get any OGRStyleToolH. Ie, the "if ( tool
> )" block never gets run, because 'tool' is always NULL at the point
> indicated by the comment. But the execution does reach that point in the
> code which indicates that the OGRStyleMrgH does in fact include at least
> one part (tool).
>
> I'd be grateful if somebody could point out what I'm doing wrong.
Nothing strikes me as wrong. A potential explanation is that styleChars
doesn't contain a valid OGR Feature Style string.
GetPartCount() counts the number of ";" separating style parts, but it doens't
check that each style part actually begins by a recognized tool name (PEN,
BRUSH, SYMBOL, LABEL). OGR_SM_GetPart() does this check however and if it
cannot recognize it it returns a NULL tool.
>
> Thanks,
> Nik.
>
>
> ---
> const char *styleChars = OGR_STBL_GetNextStyle(table) ) )
> NSString *styleName = [NSString
> stringWithUTF8String:OGR_STBL_GetLastStyleName(table)]; OGRStyleMgrH
> styleMgr = OGR_SM_Create(NULL);
> OGR_SM_InitStyleString(styleMgr, styleChars);
>
>
> for ( int i = 0; i < OGR_SM_GetPartCount(styleMgr, NULL); i++ )
> {
> OGRStyleToolH tool = OGR_SM_GetPart(styleMgr, i, NULL);
>
> if ( tool ) // 'tool' always NULL here
> {
> switch ( OGR_ST_GetType(tool) )
> {
> case OGRSTCPen:
> self.pen = tool;
> break;
>
> case OGRSTCBrush:
> self.brush = tool;
> break;
>
> case OGRSTCSymbol:
> self.symbol = tool;
> break;
>
> case OGRSTCLabel:
> self.label = tool;
> break;
>
> default:
> NSLog(@"Unknown style tool type!");
> break;
> }
> }
> }
> ---
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Need some info on geotiff tags missing
thx Even for explanation. Also I see the real important for some software is the presence of this section: Keyed_Information: GTRasterTypeGeoKey (Short,1): RasterPixelIsPoint End_Of_Keys. It can have two possibl values: RasterPixelIsPoint or RasterPixelIsArea Seem that without a value for GTRasterTypeGeoKey some software don't work. Is possible configure gdal to add this values when converting a tif+tfw to a geotiff ? Andrea. 2014-08-03 10:49 GMT+02:00 Even Rouault : > Le samedi 02 août 2014 23:48:54, Andrea Peri a écrit : >> Hi, >> >> I have transform many old tiff+tfw rasters using this gdal transformation: >> >> gdal_translate -ot Byte -of GTiff -b 1 -a_nodata none -stats -co >> COMPRESS=NONE -co INTERLEAVE=PIXEL -co PROFILE=GDALGeoTIFF -co >> TILED=YES -co BLOCKXSIZE=256 -co BLOCKYSIZE=256 -co SPARSE_OK=TRUE -co >> TFW=NO filein.tif fileout.tif >> >> They are wrking correctly with qgis and with mapserver for several months. >> >> Now I need to use this geotiffs with another program. >> But this program say that these images are not realy GeoTiffs. >> >> I test them using listgeos and have this result: >> >> TIFFReadDirectory: Warning, Unknown field with tag 42112 (0xa480) >> encountered. Geotiff_Information: >>Version: 1 >>Key_Revision: 1.0 >>Tagged_Information: >> ModelTiepointTag (2,3): >> 000 >> 559417.4456374927786.430528 0 >> ModelPixelScaleTag (1,3): >> 0.5 0.5 0 >> End_Of_Tags. >>Keyed_Information: >> End_Of_Keys. >>End_Of_Geotiff. >> >> Some people say me that this is not a true geotiff because are missing >> several tags. >> I reported a supposed response from a real geotiff: >> >> Geotiff_Information: >> Version: 1 >> Key_Revision: 1.0 >> Tagged_Information: >>ModelTiepointTag (2,3): >> 0 0 0 >> 6733474298291 0 >>ModelPixelScaleTag (1,3): >> 1 1 1 >>End_Of_Tags. >> Keyed_Information: >>GTModelTypeGeoKey (Short,1): ModelTypeProjected >>GTRasterTypeGeoKey (Short,1): RasterPixelIsArea >>GTCitationGeoKey (Ascii,37): "NAIP 2012 >> m_3808409_sw_16_1_20120607" >>ProjectedCSTypeGeoKey (Short,1): PCS_NAD83_UTM_zone_16N >>PCSCitationGeoKey (Ascii,21): "NAD83 / UTM zone 16N" >>ProjLinearUnitsGeoKey (Short,1): Linear_Meter >>End_Of_Keys. >> End_Of_Geotiff. >> >> PCS = 26916 (NAD83 / UTM zone 16N) >> Projection = 16016 (UTM zone 16N) >> Projection Method: CT_TransverseMercator >> ProjNatOriginLatGeoKey: 0.00 ( 0d 0' 0.00"N) >> ProjNatOriginLongGeoKey: -87.00 ( 87d 0' 0.00"W) >> ProjScaleAtNatOriginGeoKey: 0.999600 >> ProjFalseEastingGeoKey: 50.00 m >> ProjFalseNorthingGeoKey: 0.00 m >> GCS: 4269/NAD83 >> Datum: 6269/North American Datum 1983 >> Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31) >> Prime Meridian: 8901/Greenwich (0.00/ 0d 0' 0.00"E) >> Projection Linear Units: 9001/metre (1.00m) >> >> Corner Coordinates: >> Upper Left( 673347.000, 4298291.000) ( 85d 0'12.06"W, >> 38d48'58.87"N) >> Lower Left( 673347.000, 4290632.000) ( 85d 0'18.99"W, >> 38d44'50.54"N) >> Upper Right ( 679532.000, 4298291.000) ( 84d55'55.75"W, >> 38d48'54.41"N) >> Lower Right ( 679532.000, 4290632.000) ( 84d56' 2.92"W, >> 38d44'46.10"N) >> Center( 676439.500, 4294461.500) ( 84d58' 7.43"W, >> 38d46'52.50"N) >> >> - >> >> I'm a bit confused. >> Because I have produced my GeoTiffs using gdal. And if it fail to >> produce a real geotiff I have a trouble. >> >> So the main question is a geotiff ith only the tags reported a real geotiff >> ? > > Andrea, > > The difference between the 2 geotiff is that the first one does not have > information on the spatial reference system, but only the geotransform that > comes from the .tfw file. > Skimming quickly through the GeoTIFF specification ( > http://www.remotesensing.org/geotiff/spec/contents.html ) doesn't immediately > show if it is valid or not, although it would be best if readers are robust to > missing information. > If you know the SRS of the maps, you can try adding -a_srs EPSG: or -a_srs > wkt_string. > You could also try -a_srs "LOCAL_CS[\"Unknown\"]" if you don't know the SRS at > all. This will write a few geotiff keys to define a unknown CRS, but it is not > obvious that your reader will like it. > > Even > > -- > Geospatial professional services > http://even.rouault.free.fr/services.html -- - Andrea Peri . . . . . . . . . qwerty àèìòù - ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Feature style page
Le dimanche 03 août 2014 11:51:28, Nik Sands a écrit : > There might also be some issues in the sample code, including lines such > as: > > for (i=0;iGetPartCount();i++) > > and: > > poStyleTool = GetPart(i); > > (or otherwise it's possible I'm completely misunderstanding some of the > code) Feel free to submit a patch fixing those issues. Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Usage of styles in C API
I'm just starting out using the styles features of OGR (using the C API) but at
struggling with a few elements of it.
My code (copied below) fails to get any OGRStyleToolH. Ie, the "if ( tool )"
block never gets run, because 'tool' is always NULL at the point indicated by
the comment. But the execution does reach that point in the code which
indicates that the OGRStyleMrgH does in fact include at least one part (tool).
I'd be grateful if somebody could point out what I'm doing wrong.
Thanks,
Nik.
---
const char *styleChars = OGR_STBL_GetNextStyle(table) ) )
NSString *styleName = [NSString
stringWithUTF8String:OGR_STBL_GetLastStyleName(table)];
OGRStyleMgrH styleMgr = OGR_SM_Create(NULL);
OGR_SM_InitStyleString(styleMgr, styleChars);
for ( int i = 0; i < OGR_SM_GetPartCount(styleMgr, NULL); i++ )
{
OGRStyleToolH tool = OGR_SM_GetPart(styleMgr, i, NULL);
if ( tool ) // 'tool' always NULL here
{
switch ( OGR_ST_GetType(tool) )
{
case OGRSTCPen:
self.pen = tool;
break;
case OGRSTCBrush:
self.brush = tool;
break;
case OGRSTCSymbol:
self.symbol = tool;
break;
case OGRSTCLabel:
self.label = tool;
break;
default:
NSLog(@"Unknown style tool type!");
break;
}
}
}
---
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Feature style page
There might also be some issues in the sample code, including lines such as: for (i=0;iGetPartCount();i++) and: poStyleTool = GetPart(i); (or otherwise it's possible I'm completely misunderstanding some of the code) On 3 Aug 2014, at 7:22 pm, Martin Landa wrote: > Hi, > > 2014-08-03 11:19 GMT+02:00 Even Rouault : > >> Good catch. Actually the images were only on the www.gdal.org site and not in >> SVN ! Luckily I had made a backup of the old doc before RFC 46 in >> http://www.gdal.org/1.11, so I could fetch them back from there. During the >> next refresh from SVN they should be reinstalled. In the meantime you can see >> them from http://www.gdal.org/1.11/ogr/ogr_feature_style.html > > cool, thanks a lot for super-quick fix! Martin > > -- > Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa > ___ > 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] Feature style page
Hi, 2014-08-03 11:19 GMT+02:00 Even Rouault : > Good catch. Actually the images were only on the www.gdal.org site and not in > SVN ! Luckily I had made a backup of the old doc before RFC 46 in > http://www.gdal.org/1.11, so I could fetch them back from there. During the > next refresh from SVN they should be reinstalled. In the meantime you can see > them from http://www.gdal.org/1.11/ogr/ogr_feature_style.html cool, thanks a lot for super-quick fix! Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Feature style page
Le dimanche 03 août 2014 10:52:00, Martin Landa a écrit : > Hi, > > small note, the page about feature styles [1] lacks images. Good catch. Actually the images were only on the www.gdal.org site and not in SVN ! Luckily I had made a backup of the old doc before RFC 46 in http://www.gdal.org/1.11, so I could fetch them back from there. During the next refresh from SVN they should be reinstalled. In the meantime you can see them from http://www.gdal.org/1.11/ogr/ogr_feature_style.html Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Feature style page
Hi, small note, the page about feature styles [1] lacks images. Martin [1] http://www.gdal.org/ogr_feature_style.html -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Need some info on geotiff tags missing
Le samedi 02 août 2014 23:48:54, Andrea Peri a écrit : > Hi, > > I have transform many old tiff+tfw rasters using this gdal transformation: > > gdal_translate -ot Byte -of GTiff -b 1 -a_nodata none -stats -co > COMPRESS=NONE -co INTERLEAVE=PIXEL -co PROFILE=GDALGeoTIFF -co > TILED=YES -co BLOCKXSIZE=256 -co BLOCKYSIZE=256 -co SPARSE_OK=TRUE -co > TFW=NO filein.tif fileout.tif > > They are wrking correctly with qgis and with mapserver for several months. > > Now I need to use this geotiffs with another program. > But this program say that these images are not realy GeoTiffs. > > I test them using listgeos and have this result: > > TIFFReadDirectory: Warning, Unknown field with tag 42112 (0xa480) > encountered. Geotiff_Information: >Version: 1 >Key_Revision: 1.0 >Tagged_Information: > ModelTiepointTag (2,3): > 000 > 559417.4456374927786.430528 0 > ModelPixelScaleTag (1,3): > 0.5 0.5 0 > End_Of_Tags. >Keyed_Information: > End_Of_Keys. >End_Of_Geotiff. > > Some people say me that this is not a true geotiff because are missing > several tags. > I reported a supposed response from a real geotiff: > > Geotiff_Information: > Version: 1 > Key_Revision: 1.0 > Tagged_Information: >ModelTiepointTag (2,3): > 0 0 0 > 6733474298291 0 >ModelPixelScaleTag (1,3): > 1 1 1 >End_Of_Tags. > Keyed_Information: >GTModelTypeGeoKey (Short,1): ModelTypeProjected >GTRasterTypeGeoKey (Short,1): RasterPixelIsArea >GTCitationGeoKey (Ascii,37): "NAIP 2012 > m_3808409_sw_16_1_20120607" >ProjectedCSTypeGeoKey (Short,1): PCS_NAD83_UTM_zone_16N >PCSCitationGeoKey (Ascii,21): "NAD83 / UTM zone 16N" >ProjLinearUnitsGeoKey (Short,1): Linear_Meter >End_Of_Keys. > End_Of_Geotiff. > > PCS = 26916 (NAD83 / UTM zone 16N) > Projection = 16016 (UTM zone 16N) > Projection Method: CT_TransverseMercator > ProjNatOriginLatGeoKey: 0.00 ( 0d 0' 0.00"N) > ProjNatOriginLongGeoKey: -87.00 ( 87d 0' 0.00"W) > ProjScaleAtNatOriginGeoKey: 0.999600 > ProjFalseEastingGeoKey: 50.00 m > ProjFalseNorthingGeoKey: 0.00 m > GCS: 4269/NAD83 > Datum: 6269/North American Datum 1983 > Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31) > Prime Meridian: 8901/Greenwich (0.00/ 0d 0' 0.00"E) > Projection Linear Units: 9001/metre (1.00m) > > Corner Coordinates: > Upper Left( 673347.000, 4298291.000) ( 85d 0'12.06"W, > 38d48'58.87"N) > Lower Left( 673347.000, 4290632.000) ( 85d 0'18.99"W, > 38d44'50.54"N) > Upper Right ( 679532.000, 4298291.000) ( 84d55'55.75"W, > 38d48'54.41"N) > Lower Right ( 679532.000, 4290632.000) ( 84d56' 2.92"W, > 38d44'46.10"N) > Center( 676439.500, 4294461.500) ( 84d58' 7.43"W, > 38d46'52.50"N) > > - > > I'm a bit confused. > Because I have produced my GeoTiffs using gdal. And if it fail to > produce a real geotiff I have a trouble. > > So the main question is a geotiff ith only the tags reported a real geotiff > ? Andrea, The difference between the 2 geotiff is that the first one does not have information on the spatial reference system, but only the geotransform that comes from the .tfw file. Skimming quickly through the GeoTIFF specification ( http://www.remotesensing.org/geotiff/spec/contents.html ) doesn't immediately show if it is valid or not, although it would be best if readers are robust to missing information. If you know the SRS of the maps, you can try adding -a_srs EPSG: or -a_srs wkt_string. You could also try -a_srs "LOCAL_CS[\"Unknown\"]" if you don't know the SRS at all. This will write a few geotiff keys to define a unknown CRS, but it is not obvious that your reader will like it. Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] export to postgis, ogc_fid_seq
Le dimanche 03 août 2014 00:14:30, Martin Landa a écrit : > Hi, > > when exporting features to PostGIS layer (python script) I discovered > that ogc_fid_seq is not updated. > > Eg. > > > select last_value from stavebniobjekty_ogc_fid_seq; > last_value > > 1 > select max(ogc_fid) from stavebniobjekty; > max > -- > 2572 > > Any idea what is missing in my script? Thanks, Martin Does your script explicitely set the FID before calling CreateFeature() ? If so, then the COPY (or INSERT if you use PG_USE_COPY = NO, but both have the same effect) will explicitely affect the ogc_fid column of the features, which has the effect of not incrementing the sequence. You likely need to explicitely call setval() -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Need some info on geotiff tags missing
Hi, I resolve my troubles. The geotiff as generate from gdal seem to be the minimal necessary tags for a geotiff. I tested the production using geotifcp tool and compare the with that produced using gdal. They are the same. So I guess the gdal tags are the minimal necessary to have a good geotiff. And the geotiff is correct. Sorry for noise, Andrea. 2014-08-02 23:48 GMT+02:00 Andrea Peri : > Hi, > > I have transform many old tiff+tfw rasters using this gdal transformation: > > gdal_translate -ot Byte -of GTiff -b 1 -a_nodata none -stats -co > COMPRESS=NONE -co INTERLEAVE=PIXEL -co PROFILE=GDALGeoTIFF -co > TILED=YES -co BLOCKXSIZE=256 -co BLOCKYSIZE=256 -co SPARSE_OK=TRUE -co > TFW=NO filein.tif fileout.tif > > They are wrking correctly with qgis and with mapserver for several months. > > Now I need to use this geotiffs with another program. > But this program say that these images are not realy GeoTiffs. > > I test them using listgeos and have this result: > > TIFFReadDirectory: Warning, Unknown field with tag 42112 (0xa480) encountered. > Geotiff_Information: >Version: 1 >Key_Revision: 1.0 >Tagged_Information: > ModelTiepointTag (2,3): > 000 > 559417.4456374927786.430528 0 > ModelPixelScaleTag (1,3): > 0.5 0.5 0 > End_Of_Tags. >Keyed_Information: > End_Of_Keys. >End_Of_Geotiff. > > Some people say me that this is not a true geotiff because are missing > several tags. > I reported a supposed response from a real geotiff: > > Geotiff_Information: > Version: 1 > Key_Revision: 1.0 > Tagged_Information: >ModelTiepointTag (2,3): > 0 0 0 > 6733474298291 0 >ModelPixelScaleTag (1,3): > 1 1 1 >End_Of_Tags. > Keyed_Information: >GTModelTypeGeoKey (Short,1): ModelTypeProjected >GTRasterTypeGeoKey (Short,1): RasterPixelIsArea >GTCitationGeoKey (Ascii,37): "NAIP 2012 > m_3808409_sw_16_1_20120607" >ProjectedCSTypeGeoKey (Short,1): PCS_NAD83_UTM_zone_16N >PCSCitationGeoKey (Ascii,21): "NAD83 / UTM zone 16N" >ProjLinearUnitsGeoKey (Short,1): Linear_Meter >End_Of_Keys. > End_Of_Geotiff. > > PCS = 26916 (NAD83 / UTM zone 16N) > Projection = 16016 (UTM zone 16N) > Projection Method: CT_TransverseMercator > ProjNatOriginLatGeoKey: 0.00 ( 0d 0' 0.00"N) > ProjNatOriginLongGeoKey: -87.00 ( 87d 0' 0.00"W) > ProjScaleAtNatOriginGeoKey: 0.999600 > ProjFalseEastingGeoKey: 50.00 m > ProjFalseNorthingGeoKey: 0.00 m > GCS: 4269/NAD83 > Datum: 6269/North American Datum 1983 > Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31) > Prime Meridian: 8901/Greenwich (0.00/ 0d 0' 0.00"E) > Projection Linear Units: 9001/metre (1.00m) > > Corner Coordinates: > Upper Left( 673347.000, 4298291.000) ( 85d 0'12.06"W, > 38d48'58.87"N) > Lower Left( 673347.000, 4290632.000) ( 85d 0'18.99"W, > 38d44'50.54"N) > Upper Right ( 679532.000, 4298291.000) ( 84d55'55.75"W, > 38d48'54.41"N) > Lower Right ( 679532.000, 4290632.000) ( 84d56' 2.92"W, > 38d44'46.10"N) > Center( 676439.500, 4294461.500) ( 84d58' 7.43"W, > 38d46'52.50"N) > > - > > I'm a bit confused. > Because I have produced my GeoTiffs using gdal. And if it fail to > produce a real geotiff I have a trouble. > > So the main question is a geotiff ith only the tags reported a real geotiff ? > > Thx, > > -- > - > Andrea Peri > . . . . . . . . . > qwerty àèìòù > - -- - Andrea Peri . . . . . . . . . qwerty àèìòù - ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL High dynamic range images
Le dimanche 03 août 2014 01:05:45, Rashad M a écrit : > On Sat, Aug 2, 2014 at 8:29 PM, Even Rouault > > wrote: > > Le mercredi 30 juillet 2014 15:04:42, Rashad M a écrit : > > > Hello all, > > > > > > > > > Is it possible to read high dynamic range files using GDAL? > > > > Not currently. And HDR seems to refer more to a general technique than a > > well > > established format. So getting support for your file might depend on the > > specific format of the camera maker. > > Ok. But cant it be handled by a new gdal driver? > Yes, I guess it could. -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] SetSpatialFilter
Le dimanche 03 août 2014 09:03:57, tunca tunc a écrit : > Thanks Even, > It works now. > Are Latitude and Longitude values are inverted in gdal. Most GIS and GIS formats work with longitude, latitude coordinate order since it allows to draw a map that makes sense when using longitude as the horizontal axis and the latitude as the vertical axis of a euclidian plan. > > Best Regards > Tunca -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] SetSpatialFilter
Thanks Even, It works now. Are Latitude and Longitude values are inverted in gdal. Best Regards Tunca ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
