Hi,
It looks like the sql queries with -dialect "OGRSQL" doesn't seem to work
as expected. When I specify the FID in the where clause, it doesn't filter
anything. The same query is also described as a solution in the following
ticket https://trac.osgeo.org/gdal/ticket/4253 but I doubt if that wor
Hi,
I did not use osmconf.ini in any particular way. As you can read from the
driver documentation https://gdal.org/drivers/vector/osm.html OSM driver reads
the configuration from the osmconf.ini file. Because I did not edit my
osmconf.ini and obviously you did not edit yours then we have been
A quick look at the GDAL source in
gdal-3.0.1\ogr\ogrsf_frmts\aeronavfaa\ograeronavfaadatasource.cpp suggests that
the code is not processing the file format correctly and therefore not
identifying the file as a Daily DOF. I would try to fix it, but I can't get
PROJ to build on Windows using V
Thanks guys for clarification!
On Wed, Sep 4, 2019, 5:53 PM Even Rouault
wrote:
> On mercredi 4 septembre 2019 17:26:14 CEST Denis Rykov wrote:
> > Thanks for quick reply, I've uploaded grib file here:
> > https://transfer.sh/5JCVX/download.grib
>
> Turns out that my guess wasn't so bad after al
Hi Even,
Thanks for your kindly attention. I'm sad that I couldn't provide you a proper
material to reproduce the issue (since I didn't own them).
But I think I just found the cause of this problem - lack of memory.
From your suggestion about using a debugger, I searched the internet and found
I have updated my C# application to use the GDAL 3.0.1 binaries from
GISInternals.
Transform via EPSG:
var src = new SpatialReference("");
var dest = new SpatialReference("");
string wkt = "POINT(2575957.917 5728085.530)";
var geom = Geometry.CreateFromWkt(wkt);
On mercredi 4 septembre 2019 17:26:14 CEST Denis Rykov wrote:
> Thanks for quick reply, I've uploaded grib file here:
> https://transfer.sh/5JCVX/download.grib
Turns out that my guess wasn't so bad after all. The uncompressed file size is
3601x1801x14(bands)x8(bytes_per_pixel) = 693 MB
whereas a G
Sorry for asking, but how did you use the inifile?
Kind regards,
Paul
> 4 sep. 2019 kl. 16:22 skrev jratike80 :
>
> I can't tell what goes wrong but your command works for me and new tables
> have this much features:
>
> points "809161"
> lines "1517114"
> multilinestrings "9812"
> multipolygons
I cannot reproduce with a test_sum.vrt relying on a tiny 20x20 raster:
max
Python
byte.tif
1
$ GDAL_VRT_ENABLE_PYTHON=YES python swig/python/scripts/gdal_retile.py -v -r
bilinear -levels 5 -ps 2048 2048 -co "TILED=YES" -co "CO
Thanks for quick reply, I've uploaded grib file here:
https://transfer.sh/5JCVX/download.grib
On Wed, Sep 4, 2019 at 5:04 PM Even Rouault
wrote:
> On mercredi 4 septembre 2019 08:50:09 CEST Sean Gillies wrote:
> > Hi Denis,
> >
> > rio-convert lacks some of the features of gdal_translate (advanc
On mercredi 4 septembre 2019 08:50:09 CEST Sean Gillies wrote:
> Hi Denis,
>
> rio-convert lacks some of the features of gdal_translate (advanced metadata
> translation, statistics, &c) and it may be that the cost of those features
> is being especially felt in the GRIB case.
For a plain gdal_tra
Hi Denis,
rio-convert lacks some of the features of gdal_translate (advanced metadata
translation, statistics, &c) and it may be that the cost of those features
is being especially felt in the GRIB case. In fact, the core of
gdal_translate has some GRIB-specific code that rasterio does not use:
ht
I can't tell what goes wrong but your command works for me and new tables
have this much features:
points "809161"
lines "1517114"
multilinestrings "9812"
multipolygons "3317706"
other_relations "12587"
I used the default osmconf.ini file and Swedish data from last night.
-Jukka Rahkonen-
pau
--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
The original shapefile specification
https://www.esri.com/library/whitepapers/pdfs/shapefile.pdf informs about
filenames:
"All letters in a file name are in lower case on operating systems with case
sensitive file names."
I think that it makes sense that GDAL converts the non-standard names of
sha
Hi Lars,
I get among others:
WFS3 -vector- (ro): OGC WFS 3 client (Web Feature Service)
HTF -vector- (rov): Hydrographic Transfer Vector
AeronavFAA -vector- (rov): Aeronav FAA
Geomedia -vector- (ro): Geomedia .mdb
Kul att höra ifrån dig!
/Paul
Från: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.o
Hi Paul,
if You do: gdalinfo --formats | grep AERONAVFAA
does your format show up?
I could be that You have to make your own build to have AERONAVFAA included.
It doesn't show up in my debian build.
/Lars
4 september 2019 kl. 14:46, paul.m...@lfv.se (mailto:paul.m...@lfv.se) skrev:
Hi,
use: osm2pgsqql or imposm instead
/Lars
4 september 2019 kl. 15:00, paul.m...@lfv.se (mailto:paul.m...@lfv.se) skrev:
Hi,
When I try to convert an open street map directory to a postgis data
base I only get one layer(other_relations) with some lines and some points, far
from ev
When I import a shape layer to a postgis db with ogr2ogr, the table-name only
gets lower characters (railroads) even though the shapefile is named like
RailRoads.shp. Is there a way to force the parser to use the same characters as
the filename
___
gd
Hi,
When I try to convert an open street map directory to a postgis data base I
only get one layer(other_relations) with some lines and some points, far from
everything. There are no error meassages.
ogr2ogr-f "PostgreSQL" PG:"host= 127.0.0.1 user=postgres dbname=test
password=postgres" c:\temp
Hi,
I don't know if this is the correct forum.
I would like to fonvert a aeronavFAA obstacle file to the Esri shape format.
>From all the information I can find on internet I think this should be correct:
C:\Program Files\GDAL>ogr2ogr -f "ESRI Shapefile" c:\temp\FAAdof13_ga
C:\Downloads\FAA_DOF\1
Why gdal_translate so slow compared to rio translate from rasterio?
rio convert:
$ time rio convert download.grib download.tif
Warning: Inside GRIB2Inventory, Message # 15
ERROR: Ran out of file reading SECT0
Warning: Inside GRIB2Inventory, Message # 15
ERROR: Ran out of file reading SECT0
rio co
22 matches
Mail list logo
