bly the biggest one.
Thanks for your feedback so far. Everyone loves a good WMS 1.3.0
discussion :)
Tim
On 02/03/2016 9:58 AM, Timothy Astle wrote:
Does anyone know why the WMS Driver defaults to version 1.1.1 instead
of 1.3.0 by default? Does anyone have any objections with this
changing
Does anyone know why the WMS Driver defaults to version 1.1.1 instead of
1.3.0 by default? Does anyone have any objections with this changing to
1.3.0? It seems like 1.3.0 would fall more into line with the
specifications content negotiation.
https://github.com/OSGeo/gdal/blob/trunk/gdal/frm
Oh, I'm sorry then. I better not break your workflow :-P
I'll open up a pull request.
Tim
PS. Fine job heading up OSGeo Jeff. Best of luck in the future!
On 11/02/2016 3:16 PM, Jeff McKenna wrote:
On 2016-02-11 3:01 PM, Timothy Astle wrote:
I was building GDAL on Windows today
I was building GDAL on Windows today and hit a case where the DATADIR
was defined with a path that did not end with a backslash. That resulted
in the following prompts:
Does D:\yadda\yadda\gdal specify a file name
or directory name on the target
(F = file, D = directory)?
I was wondering if it
I just tried to build the head of the GDAL trunk with the following
commented out in the opt file:
#INCLUDE_OGR_FRMTS = YES
The build fails because during the compilation of ogrutils. The
compiler has no idea what GDALGeneralCmdLineProcessor or GDAL_OF_VECTOR
are. It appears that gdal.h isn
Thanks for the feedback Even, comments inline below.
On 23/11/2015 5:25 PM, Even Rouault wrote:
Tim,
Would it make sense to do something as follows? (Note: I haven't tried
this yet, I'm just soliciting early feedback so please bare with me )
if (osMinResolution.size() != 0)
{
I'm trying to open a WMS dataset using the minimally documented
MINRESOLUTION option. (http://www.gdal.org/frmt_wms.html)
When providing a way-too-fine resolution, I manage to create a raster
that exceeds GDALs 32-bit integer based dimensions. Below shows what
I'm seeing. You can see that on
Does anyone have any thoughts on this minor change to where the URL
encoding for the layer name is handled? In the pull request, I've moved
it so that it is done when the sub dataset URL is created. It just
makes things a lot clearer to work with as I know the URL can be treated
as-is when I
I've provided a patch and some context in this ticket.
http://trac.osgeo.org/gdal/ticket/5526
Thank you for your feedback!
Tim
On 18/06/2014 2:02 PM, Timothy Astle wrote:
Yes, that could be possible.
Aweb server should try to URL decode anything that has been encoded,
that is, an
, Even Rouault wrote:
Le mercredi 18 juin 2014 14:47:47, Timothy Astle a écrit :
I was thinking something like the following:
if( (pszInput[iIn] >= 'a' && pszInput[iIn] <= 'z')
|| (pszInput[iIn] >= 'A' && ps
+|| pszInput[iIn] == '"' && pszInput[iIn] == ',' )
which follows the list of special characters that may be used unencoded
within a URL.
Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
reserved characters us
Hi all,
Does anyone know why CPLEscapeString
(https://svn.osgeo.org/gdal/trunk/gdal/port/cpl_string.cpp) character
encodes characters that are valid as-is according to
http://www.ietf.org/rfc/rfc1738.txt?
I just hit a situation where I noticed the WMS driver is converting
hyphens to %2D for
12 matches
Mail list logo
