[gdal-dev] FIDN-issue
Hi , In my application I am fetching S57 data set where it is fetching FIDN with negative value which is wrong because FIDN should be in Range: 1 to 2 power 32-1 Is there any instance that any one got the same issue. If the same data source is loaded in Caris Easy view it is showing some other legal value. Please load the sample data with any application in open source it will show the same as mentioned above Thanks and Regards Nikhil Sai Parupalli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] doxygen updates
Le mardi 11 décembre 2012 06:05:40, Tyler Mitchell a écrit : > Hi guys, I'm just doing some review of the gdal/ogr utility docs and > occassionally finding some typos, etc. So if I want to fix them is > updating the gdal_utlilities.dox / ogr_utilities.dox file the right place > to do it? > > I thought there was some sort of magic dox stuff stuck into the API, but I > don't see it now. Are these files simply updated manually? No special magix. The dox files are the source documents to edit. > > Thanks! > > Tyler ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] doxygen updates
Hi guys, I'm just doing some review of the gdal/ogr utility docs and occassionally finding some typos, etc. So if I want to fix them is updating the gdal_utlilities.dox / ogr_utilities.dox file the right place to do it? I thought there was some sort of magic dox stuff stuck into the API, but I don't see it now. Are these files simply updated manually? Thanks! Tyler ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Multiple pens in OGR feature style
i never considered this possibility when writing the libkml driver. perhaps check what mapserver does?. there is not a lot that uses featurestyle. perhaps a clarification of this in the spec is in order? brian On Mon, 2012-12-10 at 09:34 -0700, David Strip wrote: > On 12/10/2012 7:29 AM, Even Rouault wrote: > > Looking at addstylestring2kml() in > > ogr/ogrsf_frmts/libkml/ogrlibkmlstyle.cpp, I > > can see that only one PEN instance will be taken into account (looking at > > the > > coulde, I would have said that it would be the last occurence...). And it > > seems > > that it is a limitation of LIBKML itself, since the Style class seems to > > accept > > only one line style. > If I'm reading the docs right, KML doesn't support multi-pen lines. > Google Earth extensions to KML, however, do allow a two-color line, so > it makes sense that LIBKML would not allow this. > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Brian Case KF7WPK r...@winkey.org ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Multiple pens in OGR feature style
Hi Marco and others, If the (DXF) writer does not support multiple strokes - can you perhaps export the same feature multiple times using the corresponding OGR features styles? Ideally, this would honour the symbol levels, if defined, in QGIS to get the same symbology. Do you think this is possible? Thanks, Andreas Am 10.12.2012 17:19, schrieb Marco Hugentobler: > Hi Even > > > > Ok, so it seems to depend on the format properties. > > Hi Even > > You are right, it seems to depend on the output driver/format. Actually > my main interest is the dxf format, it seems that one takes the first > element of the style. Don't know if there are drivers which handle > multiple pens / brushes. So probably I'll write everything into the > style string and let the driver do what's best for the concrete format. > > Thanks, > Marco > > On 10.12.2012 15:29, Even Rouault wrote: >> Selon Marco Hugentobler : >> >>> Hi >>> >>> I'm currently implementing support for OGR feature styles in the QGIS >>> vector layer export. In QGIS symbology, there is the possibility to >>> compose a symbol with multiple symbol layers, e.g. a broad black line >>> with a thin white line on top of it for a road symbol. Is this supported >>> by the OGR feature styles to have multiple pens / brushes in the same >>> symbol string? >>> I tried the style string >>> 'PEN(c:#008000,w:3mm,l:1);PEN(c:#ff,w:2mm,l:2)'. However, in a kml >>> export, only the first style seems to be picked up. So I wonder if there >>> is something wrong with my style string or if it is not supported by the >>> feature style mechanism. >> Marco, >> >> I was surprised that multiple pens were allowed, but yes, there >> doesn't seem to >> be any limitation on multiple instanciations of the same style tool in >> the spec >> or the generic code of the OGR FeatureStyle implementation. However >> I'd be >> surprised that many drivers (and formats) can handle that properly. >> >> Looking at addstylestring2kml() in >> ogr/ogrsf_frmts/libkml/ogrlibkmlstyle.cpp, I >> can see that only one PEN instance will be taken into account (looking >> at the >> coulde, I would have said that it would be the last occurence...). And >> it seems >> that it is a limitation of LIBKML itself, since the Style class seems >> to accept >> only one line style. >> >> http://code.google.com/searchframe#y2CS_eJ3ink/trunk/src/kml/dom/style.h&q=style.h%20package:libkml\.googlecode\.com >> >> >> Best regards, >> >> Even > > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Multiple pens in OGR feature style
On 12/10/2012 7:29 AM, Even Rouault wrote: Looking at addstylestring2kml() in ogr/ogrsf_frmts/libkml/ogrlibkmlstyle.cpp, I can see that only one PEN instance will be taken into account (looking at the coulde, I would have said that it would be the last occurence...). And it seems that it is a limitation of LIBKML itself, since the Style class seems to accept only one line style. If I'm reading the docs right, KML doesn't support multi-pen lines. Google Earth extensions to KML, however, do allow a two-color line, so it makes sense that LIBKML would not allow this. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Multiple pens in OGR feature style
Hi Even Ok, so it seems to depend on the format properties. Hi Even You are right, it seems to depend on the output driver/format. Actually my main interest is the dxf format, it seems that one takes the first element of the style. Don't know if there are drivers which handle multiple pens / brushes. So probably I'll write everything into the style string and let the driver do what's best for the concrete format. Thanks, Marco On 10.12.2012 15:29, Even Rouault wrote: Selon Marco Hugentobler : Hi I'm currently implementing support for OGR feature styles in the QGIS vector layer export. In QGIS symbology, there is the possibility to compose a symbol with multiple symbol layers, e.g. a broad black line with a thin white line on top of it for a road symbol. Is this supported by the OGR feature styles to have multiple pens / brushes in the same symbol string? I tried the style string 'PEN(c:#008000,w:3mm,l:1);PEN(c:#ff,w:2mm,l:2)'. However, in a kml export, only the first style seems to be picked up. So I wonder if there is something wrong with my style string or if it is not supported by the feature style mechanism. Marco, I was surprised that multiple pens were allowed, but yes, there doesn't seem to be any limitation on multiple instanciations of the same style tool in the spec or the generic code of the OGR FeatureStyle implementation. However I'd be surprised that many drivers (and formats) can handle that properly. Looking at addstylestring2kml() in ogr/ogrsf_frmts/libkml/ogrlibkmlstyle.cpp, I can see that only one PEN instance will be taken into account (looking at the coulde, I would have said that it would be the last occurence...). And it seems that it is a limitation of LIBKML itself, since the Style class seems to accept only one line style. http://code.google.com/searchframe#y2CS_eJ3ink/trunk/src/kml/dom/style.h&q=style.h%20package:libkml\.googlecode\.com Best regards, Even -- Dr. Marco Hugentobler Sourcepole - Linux & Open Source Solutions Weberstrasse 5, CH-8004 Zürich, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Multiple pens in OGR feature style
Selon Marco Hugentobler : > > Hi > > I'm currently implementing support for OGR feature styles in the QGIS > vector layer export. In QGIS symbology, there is the possibility to > compose a symbol with multiple symbol layers, e.g. a broad black line > with a thin white line on top of it for a road symbol. Is this supported > by the OGR feature styles to have multiple pens / brushes in the same > symbol string? > I tried the style string > 'PEN(c:#008000,w:3mm,l:1);PEN(c:#ff,w:2mm,l:2)'. However, in a kml > export, only the first style seems to be picked up. So I wonder if there > is something wrong with my style string or if it is not supported by the > feature style mechanism. Marco, I was surprised that multiple pens were allowed, but yes, there doesn't seem to be any limitation on multiple instanciations of the same style tool in the spec or the generic code of the OGR FeatureStyle implementation. However I'd be surprised that many drivers (and formats) can handle that properly. Looking at addstylestring2kml() in ogr/ogrsf_frmts/libkml/ogrlibkmlstyle.cpp, I can see that only one PEN instance will be taken into account (looking at the coulde, I would have said that it would be the last occurence...). And it seems that it is a limitation of LIBKML itself, since the Style class seems to accept only one line style. http://code.google.com/searchframe#y2CS_eJ3ink/trunk/src/kml/dom/style.h&q=style.h%20package:libkml\.googlecode\.com Best regards, Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Multiple pens in OGR feature style
Hi I'm currently implementing support for OGR feature styles in the QGIS vector layer export. In QGIS symbology, there is the possibility to compose a symbol with multiple symbol layers, e.g. a broad black line with a thin white line on top of it for a road symbol. Is this supported by the OGR feature styles to have multiple pens / brushes in the same symbol string? I tried the style string 'PEN(c:#008000,w:3mm,l:1);PEN(c:#ff,w:2mm,l:2)'. However, in a kml export, only the first style seems to be picked up. So I wonder if there is something wrong with my style string or if it is not supported by the feature style mechanism. Thanks for any hints, Marco -- Dr. Marco Hugentobler Sourcepole - Linux & Open Source Solutions Weberstrasse 5, CH-8004 Zürich, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Dynamically displaying the Overviews
Iam writing a custom GDAL driver (RBD format). I was able to display the base
image (overview no = -1) but for a big image(5 GB) it takes huge amount of
time.
So i was displaying its overview (ex; image has 3 overviews and i always
displays the last overview). In this case ArcGIS 10 displays image fastly
since its a overview.
But i require help on dynamically displaying the overviews (i.e 0,1,2 or 3)
when the overview image is Zoomed in/out.
IReadBlock() gets invoked only for the first time when displaying the
overview image.
Here is the code written in IReadBlock()
CPLErr RBDRasterBand::IReadBlock( int nBlockXOff, int nBlockYOff, void *
pImage )
{
RBDDataset *poGDS = (RBDDataset *) poDS;
long nBand = 0, nOVNumber = 0;
unsigned long nMinX = 0, nMaxX = 0, nMinY = 0, nMaxY = 0;
long nTileSizeX = 0, nTileSizeY = 0;
long nBandFlag;
long nBufferSize;
ICTM *pICTM;
pICTM = poGDS->pziiFile->pICTM;
nOVNumber = poGDS ->pziiFile ->nNumberOfOVs - 1; // if it has
overviews 0,1,2 it dispalys 2 Ov.
nBand = this->nBand;
if(-1 == nOVNumber)
{
nTileSizeX = poGDS->pziiFile->nXTileSize;
nTileSizeY = poGDS->pziiFile->nYTileSize;
}
else
{
nTileSizeX =
poGDS->pziiFile->pzii_LayerOVInfo[nOVNumber]->nXTileSize;
nTileSizeY =
poGDS->pziiFile->pzii_LayerOVInfo[nOVNumber]->nYTileSize;
}
//Get the RowMin, RowMax, ColMin and ColMax values
nMinX = nBlockXOff * nTileSizeX;
nMinY = nBlockYOff * nTileSizeY;
nMaxX = nMinX + nTileSizeX-1;//Zero Index
nMaxY = nMinY + nTileSizeY-1;//Zero Index
//Set the band flag
if(nBand == 1)
nBandFlag = RED_FLAG;
else if(nBand == 2)
nBandFlag = GREEN_FLAG;
else if(nBand == 3)
nBandFlag = BLUE_FLAG;
//Calculate buffer size
nBufferSize = (nMaxX + 1 - nMinX) * (nMaxY + 1 - nMinY) *
poGDS->pziiFile->nNumberOfBytesPerBand;
Call RenderRequestByOV on CTM object - it is our 3 part method
which fills the image buffer.
pICTM->RenderRequestByOV(nOVNumber,nBandFlag,nMinX,nMinY,nMaxX,nMaxY,&nBufferSize,(unsigned
char*)pImage,FALSE,0);
return CE_None ;
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/Dynamically-displaying-the-Overviews-tp5021867.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDAL Overviews selection
Iam writing a custom GDAL driver (RBD format). I was able to display the base
image (overview no = -1) but for a big image(5 GB) it takes huge amount of
time.
So i was displaying its overview (ex; image has 3 overviews and i always
displays the last overview). In this case ArcGIS 10 displays image fastly
since its a overview.
But i require help on dynamically displaying the overviews (i.e 0,1,2 or 3)
when the overview image is Zoomed in/out.
IReadBlock() gets invoked only for the first time when displaying the
overview image.
Here is the code written in IReadBlock()
CPLErr RBDRasterBand::IReadBlock( int nBlockXOff, int nBlockYOff, void *
pImage )
{
RBDDataset *poGDS = (RBDDataset *) poDS;
long nBand = 0, nOVNumber = 0;
unsigned long nMinX = 0, nMaxX = 0, nMinY = 0, nMaxY = 0;
long nTileSizeX = 0, nTileSizeY = 0;
long nBandFlag;
long nBufferSize;
ICTM *pICTM;
pICTM = poGDS->pziiFile->pICTM;
nOVNumber = poGDS ->pziiFile ->nNumberOfOVs - 1; // if it has overviews
0,1,2 it dispalys 2 Ov.
nBand = this->nBand;
if(-1 == nOVNumber)
{
nTileSizeX = poGDS->pziiFile->nXTileSize;
nTileSizeY = poGDS->pziiFile->nYTileSize;
}
else
{
nTileSizeX =
poGDS->pziiFile->pzii_LayerOVInfo[nOVNumber]->nXTileSize;
nTileSizeY =
poGDS->pziiFile->pzii_LayerOVInfo[nOVNumber]->nYTileSize;
}
//Get the RowMin, RowMax, ColMin and ColMax values
nMinX = nBlockXOff * nTileSizeX;
nMinY = nBlockYOff * nTileSizeY;
nMaxX = nMinX + nTileSizeX-1;//Zero Index
nMaxY = nMinY + nTileSizeY-1;//Zero Index
//Set the band flag
if(nBand == 1)
nBandFlag = RED_FLAG;
else if(nBand == 2)
nBandFlag = GREEN_FLAG;
else if(nBand == 3)
nBandFlag = BLUE_FLAG;
//Calculate buffer size
nBufferSize = (nMaxX + 1 - nMinX) * (nMaxY + 1 - nMinY) *
poGDS->pziiFile->nNumberOfBytesPerBand;
Call RenderRequestByOV on CTM object - it is our 3 part method which
fills the image buffer.
pICTM->RenderRequestByOV(nOVNumber,nBandFlag,nMinX,nMinY,nMaxX,nMaxY,&nBufferSize,(unsigned
char*)pImage,FALSE,0);
return CE_None ;
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/GDAL-Overviews-selection-tp5021862.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
