[OSM-dev] Osmium::handler::NodeLocationsForWays and buffered reading

[Rainer Schlönvoigt]

I was thinking of running through OSM files and performing different actions,
depending on the location of nodes and ways.

Creating a reader for a planet file and calling osmium::apply directly on it takes a very long time.
I would like to regain control every once in a while and as far as I can tell that only works when iterating using something like:
while (const osmium::memory::Buffer buffer = reader.read()) {
    osmium::apply(buffer, location_handler, myHandler);
}

As far as I understood I need to apply the location_handler first so that another handler (like myHandler in this example)
is able to gain the location of a way’s nodes.

Now that I think about it, it makes sense that the location handler also still has the information about the past loops.
Sorry for that.

But is this way of approaching it correct?
Or are there better ways?

Greetings
Rainer

> On 02.03.2015, at 19:35, Jochen Topf <jochen at remote.org> wrote:
> 
> On Mo, Mär 02, 2015 at 06:54:15 +0100, Rainer Schlönvoigt wrote:
>> Does said handler also find node locations for nodes that have not ended up in the buffer during the same read?
> 
> Not sure what you are asking. You can re-use the handler for different reads
> and the data will still be there, if thats what you are asking. But you have to
> keep in mind that not all indexes used by the handler will keep their contents
> sorted. If you are reading only one file thats usually not a problem, because
> most OSM files are sorted, but if you are reading several files this could
> bite you. The Dense* indexes are "self-sorting", the SparseMemTable ist also,
> but the Sparse*Array indexes aren't.
> 
> If you tell us a bit more about what you are trying to archieve, we might be
> able to help you further.
> 
> Jochen
> -- 
> Jochen Topf  jochen at remote.org  http://www.jochentopf.com/  +49-173-7019282

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20150302/9e124882/attachment.html>