In OSM data same sort of polygon features are typically modelled either as
closed rings or as multipolygon relations if they happen to have holes or if the
length of the outer ring exceeds the limit of 2000 nodes.
For making rendering more simple the OGR driver might have an option for
skipping th
Kedar,
Think about it...how does GetNextFeature() know what feature is next?
It's because somewhere inside the datasource handle there is probably a
variable that is keeping track of what record is next. If multiple
threads are all using the same datasource handle then this variable is
probably g
Hi Group,
I just encountered an error in writting data to image in GTiff format using
the OSGeo.GDAL.Gdal.Open command. The error message showing is ".tif
not recognised as a supported file format". The gdal librarary I am using
is gdal19dev.dll. The weird thing is the Gdal.Open command worked
Hi,
I am writing an application in Java with gdal's java bindings that reads a
zipcode layer shapefile.
I set a spatial filter of a point on the layer and get the zipcode by
reading from the layer.
...
DataSource ds = ogr.Open("path/to/shapefile");
Layer layer = ds.GetLayer(0);
...
public void get
Hello GDALERS''
Today I'm processing product MODIS MOD13A3 & MOD_Grid_monthly_1km_VI:1 km
monthly EVI,
gdalbuildvrt -hidenodata -vrtnodata "-1 1" mosaic_sinu.vrt
'HDF4_EOS:EOS_GRID:"MOD13A3.A232.h11v11.005.2006271173535.hdf":MOD_Grid_monthly_1km_VI:1
km monthly EVI' \
Even Rouault wrote:
>
>> I made a rough parallelizing test by making 4 copies of finland.osm.pbf and
>> running ogr2ogr in four separate windows. This way the total CPU load of the
>> 8 cores was staying around 50%.
>> Result: All four conversions were ready after 3 minutes (45 seconds per
>> con
Le mardi 31 juillet 2012 11:32:35, Michael Schulz a écrit :
> Dear GDAL'ers,
>
> I have currently some issues with reprojecting global datasets in
> geographic coordinates to the Mollweide projection (GDAL 1.8.0). When using
> gdalwarp like:
>
> gdalwarp -s_srs 'EPSG:4326' -t_srs '+proj=moll +lon
>
> I made a rough parallelizing test by making 4 copies of finland.osm.pbf and
> running ogr2ogr in four separate windows. This way the total CPU load of the
> 8 cores was staying around 50%.
> Result: All four conversions were ready after 3 minutes (45 seconds per
> conversion) while a single co
Hi,
Right, temporary DB was written on system disk so I repeated the test. Now
everything was for sure done on the same USB 2.0 disk (read pbf, write results
to Spatialite and handle temporaty DB). It took a bit longer but difference was
not very big: 26 minutes vs. 19 minutes when temporary DB
Hi
I’m building a tool to create/edit projected srs, geographic srs, datums
and spheroids and save them as WKTs. I’m already using
‘ogr/SpatialReference’.
Then I’d like to use the new WKTs with gdal/ogr. Here are some questions:
* Image/vector drivers construct WKT from information in the
Selon Rahkonen Jukka :
Interesting results. I'll wait a bit for your tests with SSD to turn
OSM_COMPRESS_NODES to YES. Even if doesn't bring clear advantages, I don't think
it would hurt a lot, because the extra CPU load introduced by the
compression/decompression shouldn't be that high (the compr
Even Rouault wrote:
>
>
> > Another set of tests with a brand new and quite powerful laptop.
> > Specs for the
> > computer:
> > Intel i7-2760QM @2.4 GHz processor (8 threads) Hitachi Travelstar
> > Z7K320 7200 rpm SATA disk
> > 8 GB of memory
> > Windows 7, 64-bit
> >
> > GDAL-version r24717, W
12 matches
Mail list logo
