>
> 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 lo
Selon Jeff McKenna :
> 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 stability by itself. It ca
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 stability by itself. It can be a new
> development comm
Le mercredi 09 janvier 2013 02:11:21, Stefan Keller a écrit :
> Even,
>
> Thanks for the fast response!
>
> 2013/1/9 Even Rouault :
> > (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
Even,
Thanks for the fast response!
2013/1/9 Even Rouault :
> (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) drivers
http://www.gdal
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
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 (subdirect
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,
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 :
Hi Even,
I need to reinstall my OSM database due to the l
Selon Frank Broniewski :
> 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 y
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
implement
Even Rouault wrote:
23. heinäkuuta 2012 13:27
> Le lundi 23 juillet 2012 00:09:05, Jukka Rahkonen a écrit :
>> Even Rouault mines-paris.org> writes:
>> > > > However, select with SQL feels sub-optimal.
>> > >
>> > > Yes, when you use ogr2ogr with explicit layer names, there are
>> > > optimizatio
Le lundi 23 juillet 2012 00:09:05, Jukka Rahkonen a écrit :
> Even Rouault 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 'poi
Even Rouault 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 node
> > 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.
Rahkonen Jukka 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 sqlite is
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 rough
Even Rouault wrote:
>> 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 th
>
> 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. Obvio
> 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 lay
Even Rouault mines-paris.org> writes:
>
> Selon Jukka Rahkonen mmmtike.fi>:
...
>
> > It is
> > much faster to convert all the points than select only a part of those. The
> > error message suggest that ogr2ogr is inspecting the input file more closely
> > than necessary for this use case:
Even Rouault 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 ways are
> Even Rouault 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 could then
Selon Jukka Rahkonen :
> Even Rouault 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 converting POI data
> be
Even Rouault 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 converting POI data
because it is possible to skip the slowe
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).
26 matches
Mail list logo
