Martin Lewis MLewis at ngms.eu.com writes:
I need a little help on WMS, it appears to decide that my one request should
be two and hence is slowing the whole thing up
I create an XML file and it has the following attributes for DataWindow:
UpperLeftX
Thanks Brian.
But this way you rewrite the whole image to disk. It uses lots of disk space
and takes forever.
I want to avoid that and just get the mask out to a msk file as fast as
possible.
I don't want to convert my rgba vrt mosaic.
The final objective is to get a msk file I can use with
Thanks for the post.
A little background may help - sorry about that.
This is for a software program using C++ where the user can pan a map and a
request is made to the WMS to fetch that current map in view.
I hand rolled a prototype where I issued my own WMS request setting the
'bbox' parameters
Martin Lewis MLewis at ngms.eu.com writes:
It seems that when it was originally converted to GDAL, the previous
engineer used the same 'bbox' parameters in the DataWindow extents. The
original 'width' and 'height' values are passed in the SizeX and SizeY tags
in the XML
From what you are
Thanks Jukka.
I have been having a play around and the 'width' and 'height' sent in the
WMS Request string appears to be BlockSizeX and BlockSizeY and I think I
understand now.
Removing the BlockSizeX and Y from the XML meant that block size was
defaulted to 1024 and 1024 - again resulting in
Hi,
I’m using GDAL to get the CADRG database sub-dataset list.
As an example (TOC file content):
- Only one boundary rectangle defined in “boundary rectangle section”,
- In “frame file index section”, I have two frames covering the same
area (same resolution, …, but different functional
How does one do Converting the dataset prior to 24/32 bit is advised.?
Warning: Input file
/maps/images.tmp/844219fb7ca86093d82b14376b56b875/modis-chlo
ra-201402071850.tif has a color table, which will likely lead to bad
results whe
n using a resampling method other than nearest neighbour.
Stephen Woodbridge woodbri at swoodbridge.com writes:
How does one do Converting the dataset prior to 24/32 bit is advised.?
For example with http://www.gdal.org/pct2rgb.html
-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
Selon Nicolas G nicolas.g-...@outlook.fr:
hi
yes you have well described the behaviour of the driver. The
subdatasets match the boundary rectangles
And it is very odd to have two frames with same col row
coordinates for the same boundary rectangle.
in your case you have to directly open the nitf
Hello
Based on all suggestions and comments above, I have come up with one thing.
The most important thing that could have been a road block for this project
was licence issues which was pointed by Even Rouault.
I am interested in implementing the SIFT or ASIFT algorithms for automatic
On Fri, Feb 7, 2014 at 11:10 AM, Kshitij Kansal kansa...@gmail.com wrote:
This means that the final product as a result of this product will also be
bounded by the above licences. It can not go into GDAL's main distribution
but can be used as a separate utility of GDAL for non-commercial uses
Selon Kshitij Kansal kansa...@gmail.com:
Kshitij,
I'm surprised that you mention licenses
for algorithms. What are your sources for that?
Only *implementations* can be licensed
not algorithms themselves. So if you
develop your own implementation you are free
to select the license you wish. There
Sir
I am providing the links for both the algorithms that I talked. I am new to
this licence issues thing so I would be highly grateful if you can clarify
doubts and if can proceed on working for this idea.
http://www.cs.ubc.ca/~lowe/keypoints/ (SIFT)
http://www.ipol.im/pub/art/2011/my-asift/
Hi,
Sorry for cross posting. This seems like a proj4 issue but might be gdal
related.
I've run into a problem that I think is related to a change in the EPSG
definition for EPSG:32662
The symptom is that the image after gdalwarp reprojection is about 20km
south of where it should be.
On 08/02/2014 07:11, Stephen Woodbridge wrote:
I've run into a problem that I think is related to a change in the EPSG
definition for EPSG:32662
The symptom is that the image after gdalwarp reprojection is about 20km
south of where it should be.
Please post the gdalwarp command you have
Hello Steve,
You asked for any thoughts, so here are some.
The 20km shift could easily be caused by using spherical version in
one implementation of equirectangular projection and ellipsoidal
version in the other. Amount of shift depends on the latitude.
You can find some information on these
16 matches
Mail list logo
