Even Rouault wrote:
Le vendredi 20 juillet 2012 20:58:08, Sven Geggus a écrit :
Even Rouault even.roua...@mines-paris.org wrote:
Testing with larger areas, like whole France or Europe, shows sluggish
performance when ways are built from nodes, but that's perhaps
expected.
I didn't compare
Even Rouault even.roua...@mines-paris.org wrote:
Testing with larger areas, like whole France or Europe, shows sluggish
performance when ways are built from nodes, but that's perhaps expected. I
didn't compare with other tools to know if the indexing or request strategy
is
particularly
Le vendredi 20 juillet 2012 20:58:08, Sven Geggus a écrit :
Even Rouault even.roua...@mines-paris.org wrote:
Testing with larger areas, like whole France or Europe, shows sluggish
performance when ways are built from nodes, but that's perhaps expected.
I didn't compare with other tools to
Right now I have only two
suggestions: osmconf.ini might have an option for renaming attributes.
Especially attribute names like addr:city are invalid in GML and
therefore cannot be published in WFS services before they are renamed to,
for example, addr_city.
Implement in r24696. There is
Hi,
I made a quick test with my old Windows laptop (2x1.2 GHz, 2 GB RAM) and
Finland.osm.pbf. OGR driver is a few times faster than osm2pgsql for me,
that is, 40 minutes vs. more than 2 hours on this slow computer. Osm2pgsql
spends a great deal of the extra time for indexing osm_nodes, osm_ways
Le mardi 10 juillet 2012 22:13:15, Jochen Topf a écrit :
Interesting. Any reason you wrote the whole thing yourself instead of
basing it on the Osmium library? (wiki.osm.org/wiki/Osmium)
Hi Jochen,
The main reason is I didn't make an extensive search of what other libs
existed before, so yes
Hi,
On 07/11/2012 09:24 AM, Even Rouault wrote:
The main reason is I didn't make an extensive search of what other libs
existed before, so yes perhaps, a bit of reinvented wheel syndrom...
Apart from unnecessary duplication of work - which is basically a
problem just for the authors and not
Osmium is a header-only library, so the extra dependency would only be there
for people building GDAL/OGR, not people using the library. So I'd say it is
not that bad. (And you have the dependency on spatialite now which Osmium
wouldn't need.)
Actually, the dependency for the OSM driver is
OSM has *lots* of broken data, especially broken (multi)polygons where:
* polygon rings have gaps
Not sure what you mean by that. Example ?
* inner/outer polygon rings are mis-classified (inner rings declared as
outer and vice versa)
The algorithm used in the driver ignores inner/outer
On Jul 11, 2012, at 1:03 AM, Jochen Topf wrote:
- Osmium does not seem to be Windows ready according to its doc.
Yes. I hope somebody who knows anything about Windows development will help
with that at some point.
I's really like to see the Mapnik OSM plugin switch to using Osmium rather
Hi,
This is a forward of an email I just send on the gdal dev mailing list :
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 10-07-12 21:18, Even Rouault wrote:
Following the recent brainstorming with Jukka, I've pushed into
trunk a driver to read OpenStreetMap .osm / .pbf files .
Is this driver able to replace tools such as osm2pgsql? Hence does it
integrate
Le mardi 10 juillet 2012 21:21:34, Stefan de Konink a écrit :
On 10-07-12 21:18, Even Rouault wrote:
Following the recent brainstorming with Jukka, I've pushed into
trunk a driver to read OpenStreetMap .osm / .pbf files .
Is this driver able to replace tools such as osm2pgsql?
The driver,
@openstreetmap.org
Subject: [OSM-dev] New OGR driver to read OpenStreetMap .osm / .pbf files
Hi,
This is a forward of an email I just send on the gdal dev mailing list :
Following the recent brainstorming with Jukka, I've pushed into trunk a
driver
to read OpenStreetMap .osm / .pbf
14 matches
Mail list logo
