[gdal-dev] src server down

[Sebastian E. Ovide]

Hi all,

trying to get the sources from
http://download.osgeo.org/gdal/gdal173.zipbut the server is down

thanks

-- 
Sebastian E. Ovide
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

RE: [gdal-dev] src server down

[John Donovan]

Works for me, although it may have come back up over the past 20 mins).

-JD



From: gdal-dev-boun...@lists.osgeo.org
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Sebastian E.
Ovide
Sent: 17 November 2010 10:11
To: gdal-dev
Subject: [gdal-dev] src server down


Hi all, 

trying to get the sources from
http://download.osgeo.org/gdal/gdal173.zip but the server is down

thanks

-- 
Sebastian E. Ovide






...


...
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] src server down

[Jean-Claude Repetto]

Le 17/11/2010 11:10, Sebastian E. Ovide a écrit :


trying to get the sources from
http://download.osgeo.org/gdal/gdal173.zip but the server is down



Hi,

No problems here, the server is responding.

Jean-Claude
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] what does "Ring Self-intersection at or near point" really mean ?

[Anders Moe]

Hi everyone

I'm generally getting a lot of



GDAL warning: 1 : Ring Self-intersection at or near point 382104
7.21604e+006


-- 
when importing shapefiles that are assumed to be of good quality. I dont see
these kind of errors when importing into ArcCatalog. This also leads to
OGRGeometry not being valid.

Anyone knows what's behind this ?

Thanks,
Anders
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] How do I find the anchor point in file?

[Todd Smith]

Yeah and a little more investigation on my part showed me that Arc/Info
ASCII Grid files have their origin in the upper left anyway, even though
they have their lat/long coords in the lower left.  This is from
gCore\rasterio.cpp (line 243in 1.6.2).  In my RGB reads, with a nPixelSpace
of 3 and a nBufDataSize of 1, I could get away get away with having GDAL
"flip" my file data for me by using a negative value for nLineSpace because
GDALCopyWords handled that.  Memcpy doesn't do well with a negative value
for nLineSpace :).  It looks like I'll have to have another function flip my
buffer from top to bottom after my RasterIO call.
for(int k=0; k wrote:

> I am not totally sure, but I believe that the gdal data model always uses
> the upper left corner for the origin, even on files that reference the lower
> left in space. I think this is also the way rasterio handles it.  See
> RasterIO docs:
>
> http://gdal.org/classGDALDataset.html#e077c53268d2272eebed10b891a05743
>
> Specifically the nXOff and nYOff parameters.
>
> kss
> # 
> Kyle Shannon
> Physical Science Technician
> RMRS Fire Sciences Lab
> Fire, Fuels & Smoke - RWU 4405
> 5775 Highway 10 W.
> Missoula, MT 59808
> (406)829-6954
> kshan...@fs.fed.us
> # 
>
>
>   On Tue, Nov 16, 2010 at 5:28 PM, Todd Smith wrote:
>
>>   The default way of doing things at my company is to treat the lower
>> left corner of a file as the origin.  Thus when I call RasterIO on a
>> GeoTIFF, I make the buffer I pass as pData address to the last row of the
>> buffer I've allocated, and I make nLineSpace negative.  This has the effect
>> of reading the file from the beginning, but placing each line into my buffer
>> starting at the last and finishing at the first line.  This was working
>> great until I started reading ArcInfo/Ascii files with origins in the
>> lower-left.  In this case, I wouldn't want to address to the last row of my
>> buffer, I'd want to address to the beginning of my buffer, and use a
>> positive value for my line space.
>>
>> Is there metadata that will tell me where the file's origin is?  If not,
>> any suggestions as to how to deal with this problem?
>>
>> Thanks!
>>
>> Todd
>>
>> ___
>> 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] How do I find the anchor point in file?

[Frank Warmerdam]

Todd Smith wrote:
Yeah and a little more investigation on my part showed me that Arc/Info 
ASCII Grid files have their origin in the upper left anyway, even though 
they have their lat/long coords in the lower left.  This is from 
gCore\rasterio.cpp (line 243in 1.6.2).  In my RGB reads, with a 
nPixelSpace of 3 and a nBufDataSize of 1, I could get away get away with 
having GDAL "flip" my file data for me by using a negative value for 
nLineSpace because GDALCopyWords handled that.  Memcpy doesn't do well 
with a negative value for nLineSpace :).  It looks like I'll have to 
have another function flip my buffer from top to bottom after my 
RasterIO call. 


Todd,

Negative values are supposed to be accepted for line spacings.  If you have
found a case where it fails please file a ticket on the issue.

Best regards,
--
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] How do I find the anchor point in file?

[Todd Smith]

Looking into it more closely, a setting was incorrect in my parameter file
that my code was referencing.  It was allocating the wrong size buffer
because it was thinking it was creating RGB data instead of elevation data.
No bug, and now no more problems.

Thanks,

Todd

On Wed, Nov 17, 2010 at 10:32 AM, Frank Warmerdam wrote:

> Todd Smith wrote:
>
>> Yeah and a little more investigation on my part showed me that Arc/Info
>> ASCII Grid files have their origin in the upper left anyway, even though
>> they have their lat/long coords in the lower left.  This is from
>> gCore\rasterio.cpp (line 243in 1.6.2).  In my RGB reads, with a nPixelSpace
>> of 3 and a nBufDataSize of 1, I could get away get away with having GDAL
>> "flip" my file data for me by using a negative value for nLineSpace because
>> GDALCopyWords handled that.  Memcpy doesn't do well with a negative value
>> for nLineSpace :).  It looks like I'll have to have another function flip my
>> buffer from top to bottom after my RasterIO call.
>>
>
> Todd,
>
> Negative values are supposed to be accepted for line spacings.  If you have
> found a case where it fails please file a ticket on the issue.
>
> Best regards,
> --
>
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Programmer for Rent
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] what does "Ring Self-intersection at or near point" really mean ?

[Thomas Gratier]

Hello,

I suppose it's similar to Postgis I know better. See this old post
http://www.davidgis.fr/blog/index.php?2007/05/11 to understand.
It seems to be related to OpenGIS Simple Features for
SQL

Regards

ThomasG
GIS specialist
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] KernelFilteredSource and nodata

[Boss, Ken (DNR)]

Hello list--

I am attempting to filter a raster using gdal_translate (v 1.7) and a vrt with 
a KernelFilteredSource.  The input raster contains large areas of "nodata" 
values.  I would like the filter to ignore those areas.  I have tried various 
combinations of , ,  and , but have not been able to prevent the filter from applying 
itself at data/nodata boundaries.

My current VRT and gdal_translate command lines are below.  Can anyone tell me 
what I am doing wrong?

Thanks,

Ken Boss
Minnesota DNR

= kernel_filter.vrt ===


  EPSG:26915
  19, 1000, 0, 4795000, 0, 1000
  

  interpolated.tif
  1
  255
  1
  
5
0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 
0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04
  

  


=

gdal_translate -of GTiff -ot Byte -a_srs EPSG:26915 kernel_filter.vrt 
kernel_filtered.tif

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] KernelFilteredSource and nodata

[Chaitanya kumar CH]

Ken,

The current kernel filter does not ignore the boundaries of nodata pixels.
But it does normalize the kernel after ignoring the nodata pixels in the
kernel, if the 'normalized' attribute is set to 1.

You can raise a ticket to request for this feature at
http://trac.osgeo.org/gdal/newticket


On Thu, Nov 18, 2010 at 6:08 AM, Boss, Ken (DNR) wrote:

> Hello list--
>
> I am attempting to filter a raster using gdal_translate (v 1.7) and a vrt
> with a KernelFilteredSource.  The input raster contains large areas of
> "nodata" values.  I would like the filter to ignore those areas.  I have
> tried various combinations of , ,  and
> , but have not been able to prevent the filter from
> applying itself at data/nodata boundaries.
>
> My current VRT and gdal_translate command lines are below.  Can anyone tell
> me what I am doing wrong?
>
> Thanks,
>
> Ken Boss
> Minnesota DNR
>
> = kernel_filter.vrt ===
>
> 
>  EPSG:26915
>  19, 1000, 0, 4795000, 0, 1000
>  
>
>  interpolated.tif
>  1
>  255
>  1
>  
>5
>0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04
> 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04
>  
>
>  
> 
>
> =
>
> gdal_translate -of GTiff -ot Byte -a_srs EPSG:26915 kernel_filter.vrt
> kernel_filtered.tif
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
Best regards,
Chaitanya kumar CH.
/tʃaɪθənjə/ /kʊmɑr/
+91-9494447584
17.2416N 80.1426E
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Motion: Approve RFC 33 - GeoTIFF - Fixing PixelIsPoint Interpretation

[Frank Warmerdam]

Folks,

I haven't seen any serious concerns with proceeding with this fix and I
have incorporated a few fixes.  So now I'd like to motion to adopt RFC 33:

  http://trac.osgeo.org/gdal/wiki/rfc33_gtiff_pixelispoint

+1 Frank

Best regards,
--
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev