On 2015-10-16 18:20, Even Rouault wrote:
Le vendredi 16 octobre 2015 17:57:10, Hermann Peifer a écrit :
On 2015-10-12 11:28, Even Rouault wrote:
I've changed to '%.15g' formatting for WKT in
https://trac.osgeo.org/gdal/ticket/6145
Hi Even,
Why did you choose '%.15g&
they need to be populated
with reasonable default values.
e.g. for the New Zealand Mining Grid, one could do
spatialRef.SetNZMG(centerLat = 41, centerLong = 173,
falseEasting=251, falseNorthing=6023150);
[peifer@moby:gdal]> pwd
/path/to/local/share/gdal
[peifer@moby:gdal]> grep 6023150
On 2015-10-11 19:20, Dimitrianos Savva wrote:
I just wondering if GDAL make use of any kind of custom-user-defined type that
provides higher precision from a double.
My question wasn’t so clear. The problem started comparing GDAL’s and GeoTools’
(Java) WKT representations of the same geometrie
On 2015-10-10 13:45, Dimitrianos Savva wrote:
For example the geometry POINT (4799826.09861662145704
2773995.445373429451138) cannot be represented by two double types. But
still the ExportToWKT function produces the correct result with full
precision for the values.
While thinking twice about
On 2015-10-10 17:56, Hermann Peifer wrote:
On 2015-10-10 14:06, Even Rouault wrote:
The implementation of ExportToWKT() in GDAL uses 15 decimal figures
("%.15f"
printf formatting) whatever the source precision was, and as you point,
whatever the intrinsic precision of the doubl
On 2015-10-10 14:06, Even Rouault wrote:
The implementation of ExportToWKT() in GDAL uses 15 decimal figures ("%.15f"
printf formatting) whatever the source precision was, and as you point,
whatever the intrinsic precision of the double value is.
Does "%.15f" have any added value over "%.15g"
Even Rouault-2 wrote
> This is invalid XML. > and < characters as text must be escaped.
Just as a small side remark: only < MUST be escaped in the given case.
Hermann
$ echo 'SELECT * FROM gbif_gisinput WHERE (decimallongitude >= 0)
AND (decimallongitude <= 360)' | xmlwf
STDIN:1:89: not well-for
About your initial problem:
> but gdalbuildvrt complained, informing me that
> they were not in the same projection.
What about using the below gdalbuildvrt option?
Hermann
-allow_projection_difference:
(starting with GDAL 1.7.0) When this option is specified, the utility
will accept to make
On 2014-09-03 1:24, Ravi Desai wrote:
Hello everyone,
I unziped this file:
http://www12.statcan.gc.ca/census-recensement/2011/geo/bound-limit/files-fichiers/gct_000a11a_e.zip
,
and then fed the directory into the following command:
ogr2ogr -t_srs epsg:4326 -f CSV output.csv
canada_cens
On 2014-06-03 17:45, lucvanlinden wrote:
Hi All
With upgrading to ogr 1.11 it seems that OGR2OGR -lco geom=AS_WKT, when used
in writing to a CSV output format, the WKT notation is truncated to a length
of 8000 characters.
This is/was not the case with ogr 1.10.1.
Can this be confirmed as bein
On 2014-05-06 15:04, Andrea Peri wrote:
Hi,
The IGM (Italian Geography Military) has update the definition of the
Reference System in the EPSG DB.
So now there some new codes usable for datasets in Italy:
epsg::6007, 6008, and so on.
I just checked at http://epsg-registry.org/ > retrieve by c
test
was 6707 not 6007
Thx,
Andrea.
2014-05-06 21:19 GMT+02:00 Hermann Peifer mailto:pei...@gmx.eu>>:
On 2014-05-06 15:04, Andrea Peri wrote:
Hi,
The IGM (Italian Geography Military) has update the definition
of the
Reference System in the EPSG DB.
On 2014-05-06 15:04, Andrea Peri wrote:
Hi,
The IGM (Italian Geography Military) has update the definition of the
Reference System in the EPSG DB.
So now there some new codes usable for datasets in Italy:
epsg::6007, 6008, and so on.
I just checked at http://epsg-registry.org/ > retrieve by c
Hi All,
I am looking for a way to translate grid data to GML, i.e. do something
like: gdal_translate -of gml infile.nc outfile.gml
The expected result would be something similar to [1], which is a snippet
from a related OGC document [2].
I know that this translation isn't supported by GDAL at th
Dear All,
I am wondering if someone else would be interested in a config option
like: GML_ATTRIBUTES_TO_OGR_FIELDS that would enable auto-detection of
all XML attributes and subsequently write them into the .gfs file, as
described at http://trac.osgeo.org/gdal/ticket/5418
If there is no broa
Hi,
ogrinfo tells me that the SRS in my GML file (0) is EPSG:4258 and that its
extent is somewhere around Belgium, see (1).
However, as the coordinates for the features (that are indeed from Belgium)
come in lon,lat (rather than lat,lon as defined by EPSG:4258): shouldn't the
extent be reported a
Even Rouault wrote
> Hermann,
>
> It is (was) a limitation of the GML driver. The issue is that from its
> point
> of view there's only one feature AQD_ReportingHeader, but you are
> interested
> into its sub-elements AQD_Zone, and the GML parser isn't smart enough to
> guess
> your intention.
Hi,
I have a GML file [1], which according to my understanding has 7 polygon
features [2]. ogrinfo only sees 1 feature [3], which is the last one in
document order (gml:id="ZON_NO0005_Polygon").
Can someone please tell me if the observed ogrinfo behaviour is a known
limitation of the GML driver,
On 2014-01-24 17:22, Norman Vine wrote:
hmm
this seems to be related to this fairly recent change
http://trac.osgeo.org/gdal/ticket/3732
http://osgeo-org.1560.x6.nabble.com/gdal-dev-Change-of-DECIMAL-PRECISION-in-AAIGrid-td5075524.html
I am just repeating what I wrote in the above-mentioned m
As far as I can see: lon_0 is the same in both cases and there is also
no actual difference between +datum=NAD83 (gdal) and +ellps=GRS80
+towgs84=0,0,0,0,0,0,0 (qgis).
I am not sure where +x_0=60 (qgis) comes from, but gdal's +x_0 value
is simply 6458320.41666 * 0.3048006096012192 =
On 2013-10-21 14:46, Paul Meems wrote:
I'm trying to understand how gdal_rasterize works.
As a test I'm trying to convert a shapefile with all counties of the USA
to a GeoTiff.
I've added a field to the shapefile called myID which is equal to the
shape number.
The goal is to create a tiff with ea
aborruso wrote
> I have changed only the file format, and I obtain different results.
>
> Is this normal?
It is "normal", because more than the format has been changed. Compare the
CRS definitions in png vs. tif and you'll find and additional extension
definition in the tif:
EXTENSION["PROJ4","+
aborruso wrote
> Dear all,
> I have a geospatial png file - http://ge.tt/7tmMR7r/v/0?c -and gdalinfo
> give me this projection info:
>
> PROJCS["Popular Visualisation CRS / Mercator",
> GEOGCS["Popular Visualisation CRS",
> DATUM["Popular_Visualisation_Datum",
> SPHERO
ue.
Hermann
Gesendet: Montag, 02. September 2013 um 13:30 Uhr
Von: "Casper Børgesen (CABO)"
An: peifer , "gdal-dev@lists.osgeo.org"
Betreff: RE: [gdal-dev] Change of DECIMAL_PRECISION in AAIGrid
Hi Peifer.
Thank you for your comments. They do explain more in depth wha
Casper Børgesen wrote
> This is my syntax:
>
> gdal_translate -of AAIGrid -ot Float32 -co DECIMAL_PRECISION=2
> my_source.vrt my_target.asc
>
> I have tried the above syntax using gdal 1.9.2 and 1.10 and these are
> examples from my results:
>
> 1.9.2:
> ...
> 3.77 3.83 3.89 3.87 3.79 3.49 3.03
On 2013-08-23 15:23, Even Rouault wrote:
Selon peifer :
Hi,
http://www.gdal.org/gdal_edit.html states about -a_nodata
Assign a specified nodata value to output bands.
Can be set to none to remove a nodata value if one exists for the dataset.
I assume that none means the literal string
Hi,
http://www.gdal.org/gdal_edit.html states about -a_nodata
> Assign a specified nodata value to output bands.
> Can be set to none to remove a nodata value if one exists for the dataset.
I assume that none means the literal string `none', but what happens is
given below.
Is this just a pla
Even Rouault wrote
> Le jeudi 08 août 2013 19:44:04, Hermann Peifer a écrit :
>> On 2013-08-08 9:55, ludwig.hilger wrote:
>> > Hello everybody,
>> >
>> > I am also a newbie and seem to have a similar problem, but cannot get
>> it
>> > solved. I a
On 2013-08-08 9:55, ludwig.hilger wrote:
Hello everybody,
I am also a newbie and seem to have a similar problem, but cannot get it
solved. I am trying to reproject the following file:
http://www.altmuehlnet.de/~hilger/Test_Smooth_0208_4258.tif
I am using the following line:
gdalwarp -et 0 -r bil
On 2013-06-07 6:33, Even Rouault wrote:
Selon Jukka Rahkonen :
Herman Peifer wrote but forgot to send to the list:
" Jukka,
Could you please try with -a_srs epsg:2393 instead of -s_srs epsg:2393,
see http://trac.osgeo.org/gdal/ticket/4496";
This is funny, but using -a_srs:2393 in t
FYI, some 4 years ago, I reported an XML schema validation error related
to the element: http://trac.osgeo.org/gdal/ticket/2858. IIRC,
the explanation at the time was that there are some limitations with the
kml driver and "the real solution is to switch to libkml..."
Hermann
On 2013-05-0
Hi,
gdalinfo 27002570PAS_dem.tif tells me:
...
PARAMETER["false_easting",6458320.41666],
...
UNIT["us_survey_feet",0.3048006096012192],
gdalwarp 27002570PAS_dem.tif out.tif -t_srs epsg:4326 tells me in DEBUG
mode:
OGRCT: Source: +proj=lcc +lat_1=40.97
+lat_2=39.93
On 2013-01-24 11:44, Ahmet Temiz wrote:
hello
I have a contour elevation (line) map.
I create bounding box map ( as a rectangular polygon ) of this
contour map using extend.
how can I do that ?
If I understood correctly, all you need to do is:
ogrtindex output_dataset src_dataset
http://
On 2013-01-09 16:13, Johnny wrote:
Are you aware of any way to batch process this in Linux to enable swift
conversion of multiple references?
You'd need a script that maps the 2-letter grid cell identifiers to the
respective offsets, then calculates the Easting and Northing values. I
can se
The lower left corner coordinates of the SD square are:
300 000 metres East
400 000 metres North
So your test coordinate is at (Easting Northing): 380150 402109
echo "380150 402109" | gdaltransform -s_srs EPSG:27700 -t_srs EPSG:4326
-2.30083027968938 53.5152719980087 48.8662291513756
Please no
On 2012-06-20 19:50, Even Rouault wrote:
I know this is going to sound a bit counter-intutive at first...
ogrinfo opens datasources in read/write mode by default...
Just out of curiosity: why does an ...info tool use read/write mode by
default? One would expect that it only needs to *read* s
On 19/03/2012 09:55, Jean-Claude Repetto wrote:
Hello ,
Since this morning, "./configure" of the trunk version of GDAL returns
an error :
configure: error: FileGDBAPI not found.
Tested on Linux 32 bits and Linux 64 bits.
http://osgeo-org.1560.n6.nabble.com/gdal-dev-compiling-with-FileGeodb-AP
On 16/03/2012 10:20, Jean-Claude Repetto wrote:
Le 16/03/2012 09:55, Chrishelring a écrit :
Hi all,
very simple question (atleast I hope so ;). I need to check the
version of
the ogr library included in my mapserver configuration, but cant seem to
find a way to do it. If I just enter ogr2ogr in
On 24/02/2012 20:05, Even Rouault wrote:
CC'ing the list in case someone has a better idea. I don't. Should work...
Selon Travis Kirstine:
My Command
ogr2ogr -f GML -t_srs EPSG:4326 -s_srs EPSG:900913 -nln administrative
planet_osm_polygon_boundary_administrative.gml PG:'dbname=osmdb
user=osm
On 18/02/2012 20:11, Brent Fraser wrote:
I have some shapefiles I thought I would look at in Google Earth, so I
used ogr2ogr (v1.8.1) to convert them to KML:
ogr2ogr -f "KML" Lines_OGR.kml Lines.shp
but they appeared about 100 meters Northeast of my expectation, leading
me to believe there was
On 06/02/2012 14:52, Etienne Tourigny wrote:
I have been working on experimental EPSG lookup, see ticket #4345
http://trac.osgeo.org/gdal/ticket/4345
It requires gdalsrsinfo from gdal-1.9 and some extra data files
installed in the gdal data directory (see the ticket)
It could perhaps be an
Hi all,
Could it (perhaps) make sense to have a gdal-users mailing list, in
analogy to grass-users, qgis-users, etc. ?
I assume that, according to some logic, GDAL/OGR is considered to be a
library from/for developers, not a GIS application for end-users. On the
other hand, there are quite
Another option would be to gdal_translate to a .vrt by using
-a_srs srs_def EPSG:31466
-a_nodata value # in case you happen to know
-a_ullr ulx uly lrx lry # coordinates at pixel edges, not their centre
points
Think about the .vrt as being the big brother of a world file. You might
want to s
On 08/11/2011 20:28, Even Rouault wrote:
gdalwarp something.tif something.tif -t_srs EPSG: makes no sense...
Indeed: typing 'something.tif' twice should not be necessary. But the
following could theoretically make sense (in analogy to GNU sed's
-i/--in-place switch (which creates a tempo
On 30/10/2011 20:16, Iain wrote:
But the tiles
I generate appear to be out about 1/4 degree too far north (look OK east
west) over the whole area. (the mapnik generated tiles, using background
from hill shade + colour-relief and data from openstreetmap in a postgis
database are all fine and matc
On 28/10/2011 20:08, Chaitanya kumar CH wrote:
I meant the nodata value of ch00_form.tif
This *is* the nodata value of ch00_form.tif.
The vrt which I posted has been generated through a simple:
$ gdal_translate -of vrt ch00_form.tif ch00_form.vrt
The only modifications I made was to change S
On 28/10/2011 20:02, Chaitanya kumar CH wrote:
What was the nodata value in the original?
0.00E+00
Hermann
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
On 27/10/2011 10:58, Chaitanya kumar CH wrote:
A vrt file can implement your requirements. It can create a 'lookup
table' to translate your pixel values...
Chaitanya,
I just tried to translate an Int32 GeoTIFF with pixel values 111..523
into a byte-type GeoTIFF with values 1..44, using the L
On 28/10/2011 09:09, Chaitanya kumar CH wrote:
I'm sorry. I should have said that gdalbuildvrt does not support
creation of the lookup table.
Thanks for the clarification and for posting the vrt-lookup-table trick.
This was very helpful.
Hermann
_
On 27/10/2011 14:48, Chaitanya kumar CH wrote:
However it [gdalbuildvrt] doesn't support complex sources..
Chaitanya, could you perhaps elaborate on the above statement?
joolek,
About the batch-processing of 3000 files: in my
Linux/Bash/GDAL-from-trunk environment, I would do something like
On 26/10/2011 18:32, Mateusz Łoskot wrote:
It is there: "See also GDAL wiki for other details" leading to:
http://trac.osgeo.org/gdal/wiki/mdbtools
http://trac.osgeo.org/gdal/wiki/PGeo
Aha. Now I see. Perhaps there should be a stronger warning for dumb GDAL
users like me. Something like:
On 26/10/2011 18:11, Even Rouault wrote:
IMHO, you can't. I've spent some time investigating this issues a few months ago
and my conclusion was that mdbtools was too buggy (and unmaintained), and in
particular not 64bit ready. I tried a few fixes, but finally I gave up. I've
developped the MDB d
Hi,
I have been trying to get the PGeo driver working, following the hints
at [0].
I have gotten to a partial success in so far that the driver connects to
the mdb and finds the layers and the features [1]. However, the geometry
is not understood, which seems to be related to the "importFrom
On 19/09/2011 18:41, Paul Ramsey wrote:
Wow, we just can't win can we? So the only way forward is to get
morphToEsri to produce the extract literal string representation
expected by the API? What fun.
It is really a pity: over some 500 lines of code, OGR's morphToESRI()
function tries its be
On 16/09/2011 16:49, Paul Ramsey wrote:
...perhaps in the FGDB driver we can try and
avoid using the WKT at all when we have a WKID available.
I just disabled the generation of the WKT element in my local copy of
FGdbLayer.cpp [0]: /* CPLCreateXMLElementAndValue(srs_xml,"WKT", wkt); */
If
On 16/09/2011 16:49, Paul Ramsey wrote:
On Fri, Sep 16, 2011 at 3:16 AM, Hermann Peifer wrote:
Frank, Even, Paul, et al.:
Could it perhaps make sense if the morphToESRI() function paid more
attention to these string identifiers in order to produce even more
"ESRI-friendly" WKT?
Yes
On 15/09/2011 16:46, Hermann Peifer wrote:
My quick-fix:
I edited ../local/share/gdal/pcs.csv and changed "ETRS89 / LAEA Europe"
into "ETRS 1989 / LAEA", ..et voilà: the error is gone. "ETRS 1989 /
LAEA" is ESRI'ified into "ETRS_1989_LAEA", which is
AFAICT, the issue is not so much that the FileGDB only supports certain
projections, but that it only accepts a very specific WKT string for a
given SRS. A single character of difference can cause the FileGDB API to
not recognise the SRS, then fall back to a "General function failure".
GDAL/OG
On 15/09/2011 06:17, Paul Ramsey wrote:
Interesting. I wonder if this is a mismatch between FGDB considering
the fid to be a column and ogr considering it to be something more
intrinsic... I think it warrants a ticket unless other layer types
misbehave in a similar way.
P.
Being an (innocent)
Hi again,
Once I am at it, I could also report another issue with the FileGDB driver.
The driver re-projects my test geodatabase from WGS84 to NAD83 without
any problems, but when trying to re-project to EPSG:3035 (ETRS89/LAEA
Europe), I end up with a "General function failure", see more detai
Hi All,
I am not quite sure if this is a feature or rather a bug, but OGR's
-where switch seems to be aware of the OBJECTID field in a FileGDB,
whereas the -sql option reports: 'OBJECTID' not recognised as an
available field, see below.
Would it be worth filing a ticket?
Hermann
$ ogrinf
On 11/09/2011 00:27, Stacy Supak wrote:
Hi Community,
I have discovered a problem relate to the output of an ogr2ogr command
line call. My resulting polygon features are 12 miles (.18 degrees) due
north of where they should be, but the longitude is correct. The polygon
dimensions are also preser
On 06/09/2011 17:39, Frank Warmerdam wrote:
On 11-09-06 12:54 AM, Schmitz, Uwe wrote:
So if I conclude:
ESRI and GDAL have different WKT formats. It is not
possible to write GeoTIFF files which are fully
ESRI *and* GDAL compatible.
Uwe,
I do not agree with this conclusion! However, it is
diff
On 05/09/2011 16:03, Schmitz, Uwe wrote:
I wonder, if anyone else has experienced this or
similar behaviour. And how can I achieve that
ESRI- *and* gdal-Tools can identify the correct
reference system.
What I asked on this list some weeks ago:
--- snip ---
From experience, I know that ESRI
On 01/09/2011 13:33, Even Rouault wrote:
But yes, it lacks the special case to recognize /dev/stdout as a particular
value where you must not try to write a file, which would avoid error [2].
Ticket created at http://trac.osgeo.org/gdal/ticket/4225
Yes we probably lack consistency in that
On 01/09/2011 00:28, Even Rouault wrote:
Le jeudi 01 septembre 2011 00:19:52, Elijah Robison a écrit :
ogr2ogr -f "GML" "/vsistdout/"
"C:\xData\CountyUpdate\GeoFix\feb16_polygons.shp" -sql "select * from
feb16_polygons where objectid= 2126"
ogr2ogr -f "KML" "/vsistdout/"
"C:\xData\CountyUpdate
On 31/08/2011 23:28, Even Rouault wrote:
... But it was easy to also support
/dev/stdout as an alias for /vsistdout/. Added in r23016.
Works as expected. Thanks for your time. Hermann
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.os
On 31/08/2011 22:52, Even Rouault wrote:
Yes, as a output filename, you can use the special name /vsistdout/ (you need
the trailing slash) . You likely need GDAL 1.8 or later for it to work.
Even,
Thanks for the hint. Is there a specific reason why the csv driver isn't
able to use /dev/stdo
On 28/08/2011 14:25, Even Rouault wrote:
Le samedi 27 août 2011 11:14:00, Hermann Peifer a écrit :
Matthew,
An absolute kludge-type of "solution" would be a) to make sure that the
GeoTIFF is larger than the shapefile when rasterising (in order to not
loose points at the edges) and b
On 27/08/2011 12:25, Even Rouault wrote:
Le samedi 27 août 2011 12:07:12, Hermann Peifer a écrit :
Hi,
I am just wondering why the csv driver starts numbering at 1, rather
than at 0, see e.g. the "First point" in the test.csv example at [1],
which ends up as OGRFeature(test):1.
How
Hi,
I am just wondering why the csv driver starts numbering at 1, rather
than at 0, see e.g. the "First point" in the test.csv example at [1],
which ends up as OGRFeature(test):1.
However, if I take the test.vrt/test.csv example and convert it to
shapefile format, I end up with features 0, 1
Matthew,
An absolute kludge-type of "solution" would be a) to make sure that the
GeoTIFF is larger than the shapefile when rasterising (in order to not
loose points at the edges) and b) to shift the GeoTIFF NW by 0.5 pixel
after rasterising, as I already wrote in my previous mail.
There has
On 26/08/2011 16:33, Even Rouault wrote:
Selon Hermann Peifer:
Hi,
Occasionally I use a small .asc file, which I then gdal_translate into a
bigger blank GeoTIFF. I tried to make the smallest possible test.asc
file with 1 col x 1 row and 1 cell value only, but I ended up with ERROR
4: file not
Hi,
Occasionally I use a small .asc file, which I then gdal_translate into a
bigger blank GeoTIFF. I tried to make the smallest possible test.asc
file with 1 col x 1 row and 1 cell value only, but I ended up with ERROR
4: file not recognised as a supported file format.
The error message seem
Eli, Matt,
I just rasterised some point data with GDAL 1.9dev from svn and can
confirm both observations:
a) points are lost at the edges
b) points and pixels do not line up correctly in qgis
I can align points and pixels by shifting the corner coordinates of the
resulting GeoTIFF by 0.5 pix
On 22/08/2011 14:08, Ingo Weinzierl wrote:
It says "GDAL 1.6.3, released 2009/11/19". This version comes along
with Debian Squeeze.
You have to upgrade to GDAL/OGR >= 1.8.0 in order to make use of the new
OGR SQL functionality, http://www.gdal.org/ogr/ogr_sql.html
Hermann
On 22/08/2011 13:13, Ingo Weinzierl wrote:
Hi *,
I already tried the approach below - without success. The result of
my operation is:
The command:
ogr2ogr -f "ESRI Shapefile" -sql "SELECT cast(999 as integer(3)) as
river_id from SRCShape" DESTShape.shp SRCShape.shp
The
On 19/08/2011 15:05, Ingo Weinzierl wrote:
Thanks for the quick reply, but the "-select" option only solves one
of the two parts of my problem. I still need to append a further
column that does not exist in the shapefile and which should be
defined manually.
I am not sure if I fully understood
On 12/08/2011 17:37, Even Rouault wrote:
Selon Hermann Peifer:
In fact, it is not a bug, but just one of those annoying subtelties you
encounter when playing with projections.
(...)
So :
gdal_translate dummy.asc dummy.tif -a_srs ESRI::ETRS_1989_LAEA_L52_M10.prj
Or you could just copy
Hi,
PARAMETER["Central_Meridian",10.0] from the projection file comes out
as: PARAMETER["longitude_of_center",0]
PARAMETER["Latitude_Of_Origin",52.0] is changed to
PARAMETER["latitude_of_center",0]
See the details below. Is there something wrong with my projection file
or rather with GDAL
On 26/05/2011 09:21, Jukka Rahkonen wrote:
Lefman, Jonathan ERDC-TEC-VA usace.army.mil> writes:
Hi all,
Is there an executable utility that takes the corner coordinates from a gtiff
and translates them into another projection system? For example, I have a
gtiff in UTM and I want to transla
On 24/05/2011 18:15, Lefman, Jonathan ERDC-TEC-VA wrote:
Hi all,
Is there an executable utility that takes the corner coordinates from a gtiff
and translates them into another projection system? For example, I have a
gtiff in UTM and I want to translate the coordinates of the bounding box (or
c
On 04/04/2011 05:05, Ragi Burhum wrote:
Hello list,
I am trying to test a new version of the FileGDB driver for OGR, but I
lack enough FileGDBs to test :)
Is the lack of FileGDBs still an issue? At work, we have several
hundreds of them and I could check if I can make some available.
If yo
On 05/02/2011 13:12, Even Rouault wrote:
I've just had a look, but not being neither Dutch nor a specialist of
(stereographic) projections, I don't feel competent enough to do any action on
it. Those tickets plus the reading of
http://udig.refractions.net/files/docs/api-
geotools/org/geotools/re
On 05/02/2011 00:06, Even Rouault wrote:
Unrelated with GDAL 1.8.0. The issue was that the transformation between OGC
WKT and ESRI WKT didn't handle well the Oblique Stereographic projection.
Fixed in trunk in http://trac.osgeo.org/gdal/changeset/21627
Even,
Once upon a time I opened http://
Hi,
This is most likely a minor issue, but it looks to me that the above
"should not happen" message always appears when gdal_translating a .vrt
file that refers to an .asc file. There are 2 GDALClose() for the .asc.
Hermann
$ gdal_translate --debug on laea_grid.vrt laea_grid.tif \
-co
On 06/12/2010 13:15, Even Rouault wrote:
Selon Hermann Peifer:
Even,
Thanks for the quick feedback.
Just to clarify: last week, I compiled revision 21190 from
http://svn.osgeo.org/gdal/trunk/gdal, configured
--with-libtiff=internal.
Hum OK so there's definitely a bug somewhere. Wou
/2010 11:19, Even Rouault wrote:
Selon Hermann Peifer:
Herman,
About your attempt to try to rasterize everything at once, it is likely that you
ran out of virtual memory as gdal_rasterize will load all the geometries in
memory before proceeding to the rasterization (it requires probably much more
m
Hi,
Over the weekend, I tried to gdal_rasterize a 350+ MB shapefile with
149671 polygon features into a 64116 x 61850 GeoTIFF.
I first had some trouble while trying to rasterize everything at once,
because after some time, the gdal_rasterize process got killed by the
kerned (that's how I un
On 27/10/2010 11:42, Jean-Claude Repetto wrote:
Le 27/10/2010 11:18, Jean-Claude Repetto a écrit :
Le 27/10/2010 10:32, Paul Meems a écrit :
I'm now on the gdal_warp track again. But I can't produce a PNG file.
When I use -ot PNG I get this list of supported file formats
Because the syntax i
On 25/10/2010 11:17, Paul Meems wrote:
Hi list,
I've got several png files with worldfiles.
I need them in another projection (28992 --> 3785).
I'm using gdalwarp to reproject to a tiff file and then I use
gdal_translate to create a png file again.
My original png file is about 25 kB, the warped
On 22/10/2010 18:14, Jan Tappenbeck wrote:
C:\Program Files (x86)\FWTools2.4.7>gdalwarp -r near -te 2608000
55900100 2613104.5424 5582270.5709 -of GTiff -o F:\wt_3a.tif
D:\weissenturm\streifen_3_GK2.tif
What do you expect -o to do?
BTW: -r near and -of GTiff can be dropped, as both are defa
On 13/10/2010 09:10, Jukka Rahkonen wrote:
However, the .shp part of shapefile can not grow bigger than 4 gigabytes.
Did you ever succeed in creating a, say: 3.9G .shp file?
I do remember that some time ago, I was running into problems around 2G,
which wasn't too much of a surprise, as [1] s
Hello again.
I am still running into this error with gdalinfo:
$ gdalinfo HRES_ENS_2010101000+000.grib2
ERROR 4: HRES_ENS_2010101000+000.grib2 is a grib file, but no raster
dataset was successfully identified.
gdalinfo failed - unable to open 'HRES_ENS_2010101000+000.grib2'.
However, other t
On 06/10/2010 19:35, Even Rouault wrote:
Le mercredi 06 octobre 2010 18:42:14, Eli Adam a écrit :
The results of -tap are what I expect, pixels aligned with 0,0. Although I
have a separate question at the end.
ok, I've applied the patch in trunk in r20778
Thanks.
Yesterday evening, I was t
On 06/10/2010 16:34, Frank Warmerdam wrote:
Hermann Peifer wrote:
$ gdal_rasterize --debug on --config GDAL_CACHEMAX 2000 -ot byte
-a_nodata 0 -co compress=lzw -tr 255 255 -tap -l lu001l_luxembourg -burn
1 -where CODE=111 lu001l_luxembourg.shp out.tif
OGR: OGROpen(lu001l_luxembourg.shp
On 06/10/2010 15:20, Hermann Peifer wrote:
On the other hand...
The new, target aligned tiffs do only have NODATA values, which seems to
be related to ERROR 1:
$ gdal_rasterize --debug on --config GDAL_CACHEMAX 2000 -ot byte
-a_nodata 0 -co compress=lzw -tr 255 255 -tap -l lu001l_luxembourg
On 05/10/2010 19:40, Even Rouault wrote:
Le lundi 04 octobre 2010 17:23:47, Frank Warmerdam a écrit :
gdal_translate, gdalwarp, ...
Even,
I would suggest "-tap" for "target aligned pixels" to go with "-tr". I
would think that gdalwarp, gdal_rasterize, and perhaps gdal_merge.py and
gdalbuild
On 04/10/2010 19:43, Even Rouault wrote:
Le lundi 04 octobre 2010 17:01:14, Hermann Peifer a écrit :
* do you want to round/ceil/floor ? or so that the adjusted extent
includes the exact extent ? or so that the adjusted extent is contained
inside the exact extent ?
The adjusted extend
On 04/10/2010 16:31, Even Rouault wrote:
This raises quite a few questions :
* what is a standard grid ?
Ours starts at 0,0, then goes in all directions with the given tr
* what syntax would you imagine to pass to gdal utilities to define how you want
the rounding ?
Some creation options
1 - 100 of 182 matches
Mail list logo
