Re: [gdal-dev] Problems with WMS minidriver
On 2015-04-28 11:19, Federico wrote:
Hi guys, i'm trying to get a wmts layer but i'm getting an error. I think
that i'm doing something wrong but i don't what's wrong.
URL: http://opencache.statkart.no/gatekeeper/gk/gk.open_wmts
GetCapabilities:
http://opencache.statkart.no/gatekeeper/gk/gk.open_wmts?service=WMTSrequest=GetCapabilities
Tile from WMTS:
http://opencache.statkart.no/gatekeeper/gk/gk.open_wmts?SERVICE=WMTSREQUEST=GetTileVERSION=1.0.0LAYER=matrikkel_bakgrunnSTYLE=defaultFORMAT=image/pngTILEMATRIXSET=EPSG:4326TILEMATRIX=EPSG:4326:1TILEROW=0TILECOL=2
*My XML file*
GDAL_WMS
Service name=TMS
Version1.0.0/Version
ServerUrlhttp://opencache.statkart.no/gatekeeper/gk/gk.open_wmts/lyrs=matrikkel_bakgrunnx=${x}y=${y}z=${z}/ServerUrl
/Service
Using the TMS mini driver for WMS should work for WMTS as long as the
following holds true:
* Every tile matrix has the same top-left corner
* Scale denominators increase as powers of 2
* Tile matrix identifiers can be modeled a a prefix with an incremented
identifier as seems to be the case in this instance: EPSG:4326:1,
EPSG:4326:2, EPSG:4326:3
Basically, the WMTS tile matrix set needs to be a quad tree.
That being said, I'd expect the server URL to be something like:
http://opencache.statkart.no/gatekeeper/gk/gk.open_wmts?SERVICE=WMTSREQUEST=GetTileVERSION=1.0.0LAYER=matrikkel_bakgrunnSTYLE=defaultFORMAT=image/pngTILEMATRIXSET=EPSG:4326TILEMATRIX=EPSG:4326:${z}TILEROW=${y}TILECOL=${x}
André
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Problems with WMS minidriver
Hi guys, i'm trying to get a wmts layer but i'm getting an error. I think
that i'm doing something wrong but i don't what's wrong.
URL: http://opencache.statkart.no/gatekeeper/gk/gk.open_wmts
GetCapabilities:
http://opencache.statkart.no/gatekeeper/gk/gk.open_wmts?service=WMTSrequest=GetCapabilities
Tile from WMTS:
http://opencache.statkart.no/gatekeeper/gk/gk.open_wmts?SERVICE=WMTSREQUEST=GetTileVERSION=1.0.0LAYER=matrikkel_bakgrunnSTYLE=defaultFORMAT=image/pngTILEMATRIXSET=EPSG:4326TILEMATRIX=EPSG:4326:1TILEROW=0TILECOL=2
*My XML file*
GDAL_WMS
Service name=TMS
Version1.0.0/Version
ServerUrlhttp://opencache.statkart.no/gatekeeper/gk/gk.open_wmts/lyrs=matrikkel_bakgrunnx=${x}y=${y}z=${z}/ServerUrl
/Service
DataWindow
UpperLeftX180.0/UpperLeftX
UpperLeftY90.0/UpperLeftY
LowerRightX-180.0/LowerRightX
LowerRightY-90.0/LowerRightY
TileLevel20/TileLevel
TileCountX1/TileCountX
TileCountY1/TileCountY
YOrigintop/YOrigin
/DataWindow
ProjectionEPSG:4326/Projection
BlockSizeX256/BlockSizeX
BlockSizeY256/BlockSizeY
BandsCount3/BandsCount
MaxConnections5/MaxConnections
Cache /
/GDAL_WMS
*gdalinfo from the file*
Driver: WMS/OGC Web Map Service
Files: none associated
Size is 268435456, 268435456
Coordinate System is:
GEOGCS[WGS 84,
DATUM[WGS_1984,
SPHEROID[WGS 84,6378137,298.257223563,
AUTHORITY[EPSG,7030]],
AUTHORITY[EPSG,6326]],
PRIMEM[Greenwich,0,
AUTHORITY[EPSG,8901]],
UNIT[degree,0.0174532925199433,
AUTHORITY[EPSG,9122]],
AUTHORITY[EPSG,4326]]
Origin = (180.000,90.000)
Pixel Size = (-0.01341104507,-0.00670552254)
Image Structure Metadata:
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 180.000, 90.000) (180d 0' 0.00E, 90d 0' 0.00N)
Lower Left ( 180.000, -90.000) (180d 0' 0.00E, 90d 0' 0.00S)
Upper Right (-180.000, 90.000) (180d 0' 0.00W, 90d 0' 0.00N)
Lower Right (-180.000, -90.000) (180d 0' 0.00W, 90d 0' 0.00S)
Center ( 0.000, 0.000) ( 0d 0' 0.01E, 0d 0' 0.01N)
Band 1 Block=256x256 Type=Byte, ColorInterp=Red
Overviews: 134217728x134217728, 67108864x67108864, 33554432x33554432,
16777216x16777216, 8388608x8388608, 4194304x4194304, 2097152x2097152,
1048576x1048576, 524288x524288, 262144x262144, 131072x131072, 65536x65536,
32768x32768, 16384x16384, 8192x8192, 4096x4096, 2048x2048, 1024x1024,
512x512, 256x256
Band 2 Block=256x256 Type=Byte, ColorInterp=Green
Overviews: 134217728x134217728, 67108864x67108864, 33554432x33554432,
16777216x16777216, 8388608x8388608, 4194304x4194304, 2097152x2097152,
1048576x1048576, 524288x524288, 262144x262144, 131072x131072, 65536x65536,
32768x32768, 16384x16384, 8192x8192, 4096x4096, 2048x2048, 1024x1024,
512x512, 256x256
Band 3 Block=256x256 Type=Byte, ColorInterp=Blue
Overviews: 134217728x134217728, 67108864x67108864, 33554432x33554432,
16777216x16777216, 8388608x8388608, 4194304x4194304, 2097152x2097152,
1048576x1048576, 524288x524288, 262144x262144, 131072x131072, 65536x65536,
32768x32768, 16384x16384, 8192x8192, 4096x4096, 2048x2048, 1024x1024,
512x512, 256x256
*gdal_translate from the file*
C:\gdal_translate -of JPEG -outsize 256 256 a.xml a.jpeg
Input file size is 268435456, 268435456
0ERROR 1: GDALWMS: The server returned exception: [5][Gatekeeper]
Gatekeeper logon avvist av BAAT.
ERROR 1: a.xml, band 1: IReadBlock failed at X offset 0, Y offset 0
ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 0
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Problems-with-WMS-minidriver-tp5203330.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
Re: [gdal-dev] Implementing a streaming version of KML Driver
On 04/28/2015 11:30 PM, Dmitry Baryshnikov wrote: https://code.google.com/p/libkml/downloads/list?can=1q=colspec=Filename+Summary+Uploaded+ReleaseDate+Size+DownloadCount The last release was on Feb 2010 - 5 year ago. Does the libkml still alive? Also libkml has depending on boost, and kml driver has no external depending. Google was nagged enough to move libkml to GitHub where it got some updates, but development has stopped there again too. See: https://github.com/google/libkml/ I'm in discussion with some of the libkml fork developers to get the community to take over libkml maintenance. See: https://code.google.com/p/libkml/issues/detail?id=161 https://github.com/google/libkml/issues/4 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Implementing a streaming version of KML Driver
Hello everybody, I notice that there are two KML drivers in GDAL, namely KMLDriver and LIBKMLDriver. Both of them will load all the data into memory. We would like to write a new KML driver for GDAL, a streaming version, so as to reduce memory consumption. We would still want to use LIBKML, so that we don't have to reinvent the wheels. However, the LIBKML only supports SAX API, and GDAL doesn't seems to works with that very well. I am wondering whether it is a good idea to go along this path. This is about the existing streaming parse in LIBKML (under KmlStream Section): https://code.google.com/p/libkml/wiki/KmlEngineReference https://code.google.com/p/libkml/wiki/KmlEngineReference Hope can hear some of your opinions about this idea. Sincerely, Yuchen___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Formats that support RAT's?
Le mardi 28 avril 2015 22:49:23, jramm a écrit : It seems GDAL will always let you create a Raster Attribute Table (in memory) but may fail when writing to disk depending on whether the format supports it? A lot of format that relies on the PAM(Persistant Auxiliary Metadata)Dataset base class will serialize it in a .aux.xml file. I can't seem to find any information anywhere on what formats support RAT's? Is there a list I can refer to ?? From the result of grep -r SetDefaultRAT frmts/ , the answer is Idrisi, GeoRaster, KEA and HFA. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Formats-that-support-RAT-s-tp5203365.h tml 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 -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Formats that support RAT's?
It seems GDAL will always let you create a Raster Attribute Table (in memory) but may fail when writing to disk depending on whether the format supports it? I can't seem to find any information anywhere on what formats support RAT's? Is there a list I can refer to ?? -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Formats-that-support-RAT-s-tp5203365.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
Re: [gdal-dev] Formats that support RAT's?
From: even.roua...@spatialys.com To: gdal-dev@lists.osgeo.org Date: Tue, 28 Apr 2015 22:58:16 +0200 Subject: Re: [gdal-dev] Formats that support RAT's? Le mardi 28 avril 2015 22:49:23, jramm a écrit : It seems GDAL will always let you create a Raster Attribute Table (in memory) but may fail when writing to disk depending on whether the format supports it? A lot of format that relies on the PAM(Persistant Auxiliary Metadata)Dataset base class will serialize it in a .aux.xml file. I can't seem to find any information anywhere on what formats support RAT's? Is there a list I can refer to ?? From the result of grep -r SetDefaultRAT frmts/ , the answer is Idrisi, GeoRaster, KEA and HFA. The RST format (Idrisi driver) doesn't really support RAT. That was included in the driver because, software ***, could not read GDAL Category Names at that time, but it could read read it as RAT. Don't ask me why. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Formats-that-support-RAT-s-tp5203365.h tml 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 -- Spatialys - Geospatial professional services http://www.spatialys.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] Implementing a streaming version of KML Driver
Hi, https://code.google.com/p/libkml/downloads/list?can=1q=colspec=Filename+Summary+Uploaded+ReleaseDate+Size+DownloadCount The last release was on Feb 2010 - 5 year ago. Does the libkml still alive? Also libkml has depending on boost, and kml driver has no external depending. Best regards, Dmitry 29.04.2015 00:03, Yuchen Zhong пишет: Hello everybody, I notice that there are two KML drivers in GDAL, namely KMLDriver and LIBKMLDriver. Both of them will load all the data into memory. We would like to write a new KML driver for GDAL, a streaming version, so as to reduce memory consumption. We would still want to use LIBKML, so that we don't have to reinvent the wheels. However, the LIBKML only supports SAX API, and GDAL doesn't seems to works with that very well. I am wondering whether it is a good idea to go along this path. This is about the existing streaming parse in LIBKML (under *KmlStream Section*): https://code.google.com/p/libkml/wiki/KmlEngineReference Hope can hear some of your opinions about this idea. Sincerely, Yuchen ___ 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] GDAL slow to write GeoTIFF?
Le mardi 28 avril 2015 08:25:57, jramm a écrit : By tiled do you mean split into N seperate TIFF files (in which case the answer is no), or can a single TIFF contain a tiling scheme? Yes a TIFF can be tiled internally. If so, is this some option I need to pass to the driver when creating the output? Yes TILED=YES. Cf http://www.gdal.org/frmt_gtiff.html When tiling is enabled, the default tile size is 256x256. Which would match the way you operate. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/GDAL-slow-to-write-GeoTIFF-tp5203128p5 203202.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 -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL slow to write GeoTIFF?
David, there should be no compression, but I will try setting it explicitly in the driver... -- View this message in context: http://osgeo-org.1560.x6.nabble.com/GDAL-slow-to-write-GeoTIFF-tp5203128p5203203.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
