Am 12.10.2012 18:12, schrieb Stephan Knauss:
Peter Wendorff writes:
osm2pgsql has to store nodes outside the bbox because geometries that
overlap the borders etc. should be included in the result, too.
how certain are you regarding this?
It's only based on my observations and short comments on questions
regarding that in the IRC channels.
My germany extract import took incredibly long and the number of nodes
in the slim nodes table is around in line with the data stats for
Germany as a whole, while I only imported one city (by bounding box
filtering).
in parse-primitive.c::EndElement() I see a call to node_wanted() which
only returns true if the coordinates of the node are inside the
bounding box.
it later calls osmdata->out->node_add
in output-pgsqlo.c this is pgsql_add_node which calls pgsql_nodes_set.
This is calling a prepared statement which inserts the node in the
planet_osm_nodes table.
My question is: is this code path also used during initial import?
Is this code path used during incremental updates?
My previous imports had used the xml extract as the debian protobuf
library did not work as expected. I have now also updated protobuf and
using now pbf as an input file.
The code in parse-pbf::processOsmDataNodes() does not call node_wanted().
Could it be it's simply missing there?
after this line
lon = lon_offset + (node->lon * granularity);
doing the node_wanted call and only then process the node?
In fact I imported a pbf file, so that might be the reason why you
disagree with my observations.
On the other hand the node_wanted() simple rejecting any node outside
the bbox would lead to geometries to be cut of or rejected even if
overlapping the target bounding box.
IMHO this is an acceptable behaviour as an option, but it should not be
the default.
regards
Peter
_______________________________________________
dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/dev
