[OSM-dev] osm2pgsql and bbox imports

[Peter Wendorff]

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