Selon Jeff McKenna jmcke...@gatewaygeomatics.com:
On 13-01-08 9:26 PM, Even Rouault wrote:
Ah ok, so I must mention that the online documentation is always up-to-date
with the latest trunk version (it is refreshed each night). So the fact
that
something is documented is not a sign of
There are different schools on the topic. I know Frank is not too keen on
mentionning versionning, although personnaly, I try to mention version
differences in the format page itself (http://www.gdal.org/ogr/drv_osm.html
mentions GDAL/OGR = 1.10.0). But at the end, in drivers with a lot of
Hi Even
Documentation of OpenStreetMap driver suggest its stable - but when I
recently installed the newest OGR version on a linux it was'nt there.
Is it not yet stable enough?
If not, what do you recommend?
Should I include the tagged version (currently 1.9.2) and add the
trunk version
Le mercredi 09 janvier 2013 01:02:22, Stefan Keller a écrit :
Hi Even
Documentation of OpenStreetMap driver suggest its stable
(Just curious what in the doc makes you call it stable, and what you
consider as stable)
- but when I
recently installed the newest OGR version on a linux it
Even,
Thanks for the fast response!
2013/1/9 Even Rouault even.roua...@mines-paris.org:
(Just curious what in the doc makes you call it stable, and what you
consider as stable)
Just the fact that it's there and especially that is't also in the
overview table alongside with all other (stable)
Le mercredi 09 janvier 2013 02:11:21, Stefan Keller a écrit :
Even,
Thanks for the fast response!
2013/1/9 Even Rouault even.roua...@mines-paris.org:
(Just curious what in the doc makes you call it stable, and what you
consider as stable)
Just the fact that it's there and especially
Hi,
I had this up my schedule for this week, but I see I need GDAL = 2.0.
Where might I get this? From svn (https://svn.osgeo.org/gdal/trunk/gdal)?
Thanks,
Frank
Am 2012-10-17 11:54, schrieb Even Rouault:
Selon Frank Broniewski b...@metrico.lu:
Hi Even,
I need to reinstall my OSM
Le mercredi 24 octobre 2012 09:57:58, Frank Broniewski a écrit :
Hi,
I had this up my schedule for this week, but I see I need GDAL = 2.0.
Where might I get this? From svn (https://svn.osgeo.org/gdal/trunk/gdal)?
Yes, svn trunk = GDAL 2.0dev.
___
Hi Even,
I need to reinstall my OSM database due to the license change to ODBL.
Usually I use osm2pgsql for that, but I am willing to sacrifice a little
downtime of my DB in order to test the GDAL implementation. Before
storming ahead I wanted to know how far you are with the driver
Le lundi 23 juillet 2012 00:09:05, Jukka Rahkonen a écrit :
Even Rouault even.rouault at mines-paris.org writes:
However, select with SQL feels sub-optimal.
Yes, when you use ogr2ogr with explicit layer names, there are
optimizations. For example, when you only specify the layer
Even Rouault wrote:
23. heinäkuuta 2012 13:27
Le lundi 23 juillet 2012 00:09:05, Jukka Rahkonen a écrit :
Even Rouault even.rouault at mines-paris.org writes:
However, select with SQL feels sub-optimal.
Yes, when you use ogr2ogr with explicit layer names, there are
optimizations.
Even Rouault even.rouault at mines-paris.org writes:
However, select with SQL feels sub-optimal.
Yes, when you use ogr2ogr with explicit layer names, there are
optimizations. For example, when you only specify the layer 'points', the
OSM driver will not even try to index the
Rahkonen Jukka Jukka.Rahkonen at mmmtike.fi writes:
Even Rouault wrote:
Do you have comparisons of the performance with osm2pgsql on the same
PC and
with the same data ? I'd be curious if that slow down effect is
found with every
tool, or if it is something specific to the way
However, select with SQL feels sub-optimal.
Yes, when you use ogr2ogr with explicit layer names, there are
optimizations. For example, when you only specify the layer 'points', the
OSM driver will not even try to index the nodes into the temporary
database because it is not needed.
Amenity is included in my osmconf.ini and it can be used inside -sql.
However, your example gives me this
ERROR 1: 'amenity' not recognised as an available field.
FAILURE: SetAttributeFilter(amenity='toilets') failed.
Hum, I think I know what's wrong. I see that, even if a subset of layers
Windows 7, 64-bit, SATA disk and 2x3 GHz is converting Finland.osm.pbf in
about
8 minutes for me. But execution time does not increase at all linearly.
Germany.osm.pbf is about 10 times larger in filesize but ogr2ogr had to work
about 8 hours with it, thus roughly 70 times longer. Obviously
Even Rouault wrote:
Windows 7, 64-bit, SATA disk and 2x3 GHz is converting Finland.osm.pbf in
about
8 minutes for me. But execution time does not increase at all linearly.
Germany.osm.pbf is about 10 times larger in filesize but ogr2ogr had to work
about 8 hours with it, thus roughly 70
Selon Jukka Rahkonen jukka.rahko...@mmmtike.fi:
Even Rouault even.rouault at mines-paris.org writes:
Hi,
Following the recent brainstorming with Jukka, I've pushed into trunk a
driver
to read OpenStreetMap .osm / .pbf files .
Driver seems to do what it promises. It is super fast in
Even Rouault even.rouault at mines-paris.org writes:
Following the recent brainstorming with Jukka, I've pushed into trunk a
driver
to read OpenStreetMap .osm / .pbf files .
Fascinating. Actually I think once someone imports the points, lines,
polys into a DB, then (cool!) someone
Even Rouault even.rouault at mines-paris.org writes:
Hi,
Following the recent brainstorming with Jukka, I've pushed into trunk a
driver
to read OpenStreetMap .osm / .pbf files .
.
Testing with larger areas, like whole France or Europe, shows sluggish
performance when
Hi,
Following the recent brainstorming with Jukka, I've pushed into trunk a driver
to read OpenStreetMap .osm / .pbf files .
No particularly exotic dependencies : SQLite (and Expat for OSM XML files)
See http://www.gdal.org/ogr/drv_osm.html for the details (will be available in
a few hours).
21 matches
Mail list logo
