[gdal-dev] gdaldem Roughness description
Hi, At least in my understanding the gdaldem manual's description for the Roughness is misleading. It states "Roughness is the the largest inter-cell difference of a central pixel and its surrounding cell, as defined in Wilson et al (2007, Marine Geodesy 30:3-35)." From that I understood that R = MAX(Zi-Zcentral) where Zi runs over all pixels in the rectangular neighborhood. However, what the code computes (correctly according to the paper it refers to) is R = Zmax - Zmin that is also known as the range filter in image processing. Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Fastest vector format for combining shapefiles
I'm by no way a vector expert, but for this kind of stuff I'd go the postgis way, at least for intermediate storage. I've thought of this but have shied away from it because of the overhead of installing postgis etc. just to get started. Time to get over my shyness perhaps :) cheers, matt wilkie Geomatics Analyst Information Management and Technology Yukon Department of Environment 10 Burns Road * Whitehorse, Yukon * Y1A 4Y9 867-667-8133 Tel * 867-393-7003 Fax http://environmentyukon.gov.yk.ca/geomatics/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] how to batch rgb2pct
Hi Micheal, rgb2pct is a batch file, so when used inside another batch it must be "called" in order for control to return to the initiator: call rgb2pct v:\historic_topos\rects\w\arnold-pond-w.tif v:\historic_topos\8bits\w\arnold-pond-w.tif call rgb2pct v:\historic_topos\rects\w\attean-w.tif v:\historic_topos\8bits\w\attean-w.tif call rgb2pct v:\historic_topos\rects\w\baker-lake-w.tif v:\historic_topos\8bits\w\baker-lake-w.tif If I may extend your script a little: @echo off for %%f in (arnold-pond-w.tif, attean-w.tif, baker-lake-w.tif) do ( call rgb2pct v:\historic_topos\rects\w\%%f v:\historic_topos\8bits\w\%%f ) or interactively from the command line: pushd v:\historic_topos\rects\w\ for %f in (*.tif) do rgb2pct %f ..\..\8bits\w\%f popd More info at http://ss64.com/nt/call.html cheers, matt wilkie Geomatics Analyst Information Management and Technology Yukon Department of Environment 10 Burns Road * Whitehorse, Yukon * Y1A 4Y9 867-667-8133 Tel * 867-393-7003 Fax http://environmentyukon.gov.yk.ca/geomatics/ Smith, Michael wrote: I have a .bat file which I'm trying to run, here are a few lines: rgb2pct v:\historic_topos\rects\w\arnold-pond-w.tif v:\historic_topos\8bits\w\arnold-pond-w.tif rgb2pct v:\historic_topos\rects\w\attean-w.tif v:\historic_topos\8bits\w\attean-w.tif rgb2pct v:\historic_topos\rects\w\baker-lake-w.tif v:\historic_topos\8bits\w\baker-lake-w.tif When I run the .bat it runs the first line and then just stops, returning to the windows command prompt. I can copy/paste other lines into the command prompt and they work fine. How do I get it to process the next line(s)? ** Michael Smith State GIS Manager Maine Office of GIS ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDAL Python bindings: coordinate transformation does not work
Hi,
I have just installed GDAL 1.6.1.win32-py2.6 on a Win XP system and set
up the GDAL directory properly (bin directory in PATH, env variable
points to data).
Scripts for coordinate transformation like that below do not crash, but
just seem not to do anything, i.e. the data remain unchanged instead of
being reprojected. Can anybody tell me what I am doing wrong?
Here is the sample script:
import osgeo.ogr as ogr
import osgeo.osr as osr
# CREATE WKT STRING OF POINT COORDS
sample = (' 776041.000', ' 3386618.000')
x = sample[0]
y = sample[1]
wkt = 'POINT(%s %s)' % (x, y)
# CREATE PROJECTION OBJECTS
utm16N = osr.SpatialReference ()
utm16N.ImportFromEPSG(26916)
wgs84 = osr.SpatialReference()
wgs84.ImportFromEPSG(4326)
# CREATE OGR POINT OBJECT, ASSIGN PROJECTION, REPROJECT
point = ogr.CreateGeometryFromWkt(wkt)
point.AssignSpatialReference(utm16N)
point.TransformTo(wgs84)
print wkt
print point
The output is
POINT( 776041.000 3386618.000)
POINT (776041 3386618)
where I had expected lat/long instead for point.
Thanks a lot!
Klaus
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL Python bindings: coordinate transformation does not work
On Oct 6, 2009, at 2:10 PM, Klaus Noekel wrote: Hi, I have just installed GDAL 1.6.1.win32-py2.6 on a Win XP system and set up the GDAL directory properly (bin directory in PATH, env variable points to data). Scripts for coordinate transformation like that below do not crash, but just seem not to do anything, i.e. the data remain unchanged instead of being reprojected. Can anybody tell me what I am doing wrong? The output is POINT( 776041.000 3386618.000) POINT (776041 3386618) where I had expected lat/long instead for point. Thanks a lot! Klaus Klaus, I get the following for output on my OSX box: POINT( 776041.000 3386618.000) POINT (-84.121611219545073 30.5802861582041) I suspect the TransformTo is failing because the GDAL_DATA are not being found. Howard ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL Python bindings: coordinate transformation does not work
OSGeo4W should have a suitable proj.dll Please reply to the list so others may benefit from the exchange. Howard On Oct 6, 2009, at 2:23 PM, Klaus Noekel wrote: Hi Howard, thanks for checking this so quickly. It still fails on my PC, and the env variable definitely point to the correct location. However, running in a DOS box I now see the error message ERROR 6: Unable to load PROJ.4 library (proj.dll), creation of OGRCoordinateTransformation failed. Is there another dependency that I was not aware of? Where would I find a matching PROJ.4 and where do I put it? Cheers, Klaus Howard Butler schrieb: On Oct 6, 2009, at 2:10 PM, Klaus Noekel wrote: Hi, I have just installed GDAL 1.6.1.win32-py2.6 on a Win XP system and set up the GDAL directory properly (bin directory in PATH, env variable points to data). Scripts for coordinate transformation like that below do not crash, but just seem not to do anything, i.e. the data remain unchanged instead of being reprojected. Can anybody tell me what I am doing wrong? The output is POINT( 776041.000 3386618.000) POINT (776041 3386618) where I had expected lat/long instead for point. Thanks a lot! Klaus Klaus, I get the following for output on my OSX box: POINT( 776041.000 3386618.000) POINT (-84.121611219545073 30.5802861582041) I suspect the TransformTo is failing because the GDAL_DATA are not being found. Howard ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[Fwd: Re: [gdal-dev] GDAL Python bindings: coordinate transformation does not work]
A further test revealed that the PROJ.4 DLL was missing on my system. After downloading the current version included in OSGeo4W, and putting it in the gdalwin32-1.6\bin directory, I now get the correct results. Thanks a lot, Howard! Klaus Original-Nachricht Betreff: Re: [gdal-dev] GDAL Python bindings: coordinate transformation does not work Datum: Thu, 8 Oct 2009 14:11:03 -0500 Von: Howard Butler An: Klaus Noekel CC: gdal-dev@lists.osgeo.org Referenzen: <4acb9629.50...@gmx.de> On Oct 6, 2009, at 2:10 PM, Klaus Noekel wrote: Hi, I have just installed GDAL 1.6.1.win32-py2.6 on a Win XP system and set up the GDAL directory properly (bin directory in PATH, env variable points to data). Scripts for coordinate transformation like that below do not crash, but just seem not to do anything, i.e. the data remain unchanged instead of being reprojected. Can anybody tell me what I am doing wrong? The output is POINT( 776041.000 3386618.000) POINT (776041 3386618) where I had expected lat/long instead for point. Thanks a lot! Klaus Klaus, I get the following for output on my OSX box: POINT( 776041.000 3386618.000) POINT (-84.121611219545073 30.5802861582041) I suspect the TransformTo is failing because the GDAL_DATA are not being found. Howard ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] OGC_FID vs. OGR_FID
Hi, Ogr2ogr seems to create field named ogc_fid with PostGIS driver but ogr_fid with Oracle OCI driver. Is this intentional? Probably not a big trouble for anybody. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGC_FID vs. OGR_FID
Jukka Rahkonen wrote: Hi, Ogr2ogr seems to create field named ogc_fid with PostGIS driver but ogr_fid with Oracle OCI driver. Is this intentional? Probably not a big trouble for anybody. Jukka, I believe by the time I was implementing the Oracle driver I realized naming the fid "ogc_fid was presumptuous so I used a name that was ogr oriented. I might have changed the postgres driver, except that this would likely have been disruptive for existing users. 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
[gdal-dev] RE: FW: Annotations from S-57 Files
Frank, While I wasn't able to find the OBJL=22001 and OBJL=22010 objects formally defined anywhere, I was able to back out their meaning using SeeMyEnc and some debugging in GDAL. Basically I found that 22001 is an "Annotation" point and 22010 is a "Traffic Line". I added the following 2 lines at the end of the gpapszS57Classes definition in s57tables.h. I wasn't sure of the attributes to use, is this correct (note that it seems to work fine)? "22001,Annotation,ANNOTA,ALTNAM;NOBJNM;OBJNAM;STATUS;,INFORM;NINFOM;NTXTDS;P ICREP;SCAMAX;SCAMIN;TXTDSC;,RECDAT;RECIND;SORDAT;SORIND;,G,Point;Area;", "22010,Traffic Line,TRFLNE,CATTSS;DATEND;DATSTA;STATUS;,INFORM;NINFOM;NTXTDS;SCAMAX;SCAMIN; TXTDSC;,RECDAT;RECIND;SORDAT;SORIND;,G,Line;", Likewise I added one new attribute (22076) which is an alternate name (ALTNAM). There were several other unrecognized attributes, but they seemed to carry some application-specific z-level detail. Perhaps these are custom attributes? Anyway I added the following line to gpapszS57attributes for the useful attribute carrying the names: "22076,Alternate Name,ALTNAM,S,F", Are these changes ok? I don't use the CSV files directly, but I'm guessing that perhaps the s57tables.h file is auto-generated from those or something, right? Thanks, Mike Global Mapper Support supp...@globalmapper.com -Original Message- From: Frank Warmerdam [mailto:warmer...@pobox.com] Sent: Tuesday, October 06, 2009 8:41 PM To: Michael Childs Cc: gdal-dev Subject: Re: FW: Annotations from S-57 Files Michael Childs wrote: > I am using the S57Reader class to read in S-57 data files and a user has > reported that while applications like SeeMyEnc show annotation points > with text, I cannot seem to find any returned features that include > those annotations. There is a sample data file at > http://www.globalmapper.com/Incoming/1I5LQQJ4.zip which has an > annotation that is not coming in as a point feature (see screenshot at > http://www.globalmapper.com/Incoming/SeeMyENC_DuckLake.jpg). Mike, I have inspected the file, and if I run ogrinfo on it with debug I see: S57: Unable to find definition for OBJL=22001 S57: Unable to find definition for OBJL=22010 It appears it has two S-57 object classes that don't appear in the specification (or at least the older specification I worked from). I see there is a layer called "Generic" which seems to have these objects but without extended object attributes like the text. I assume these include your annotation objects. I would suggest you dig into the S-57/ENC specifications and look for updated object catalogs and use them to extend gdal/data/s57objectclasses.csv to include these new classes. If you can feed these back into GDAL as a ticket and patch that would be fantastic. 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
