[osmosis-dev] Feature request for Osmosis

[Brett Henderson]

Hi Kenn,

Comments below.  I've also cc'd you to the osmosis dev list because 
others may have better suggestions than me.

Kenn Sebesta wrote:
> Hi--
>
> Related to a research project at the University of Luxembourg, I am
> trying to take the planet.osm and reformat it to my needs. I am using
> osmosis for this and it seems to work fine, but there is a problem
> with efficiency that I think can be fixed quite easily. Basically, I
> use osmosis to go through a file and output highways. Once I get to a
> certain number of highways, let's say 10, I need to further reduce the
> bounding box so that I when I finish I always have less than 10
> results.
>   
I don't understand what you're trying to do here.  What are the inputs, 
and what are the expected outputs for what you're trying to do?  Are you 
starting off with a single point on the map and looking for the nearest 
10 ways?  If so there is probably a better way of achieving this than 
searching through OSM data many times until the right bounding box size 
is determined.  Searching through data many times until you determine 
the correct bounding box size sounds extremely inefficient.  I may have 
misunderstood your question though.
> This is because I'm trying to get OSM running on a microcontroller, so
> I need some way to efficiently store and access OSM files. The OSM
> format takes too much space for an SD card, and while the binary
> format is smaller, it has too many nodes that are unrelated to the
> kind of navigation I want to do. I don't need any kind of write
> access, so a very simply binary search tree that encodes the node data
> is all that's necessary.
>   
It sounds like you first need to run the OSM file through some form of 
simplification tool that removes unnecessary nodes.  Marcus Wolschon's 
(he's on this list) Travelling Salesman tool has functionality like this 
I believe that you may be able to re-use.  I'd give you a link but I'm 
offline while writing this email.
> This is very easy to program, but osmosis has troubles with large
> files because it has to go through the entire file before it returns
> control to the console. I know I could just use smaller region grabs,
> and then patch it all back together, but that's kind of a hack, and is
> more prone to error. I guess this could be gotten around through some
> way of piping the data to a file and monitoring the file in another
> process, killing the original process once sufficient highways are
> found, but this isn't particularly easy to do, especially for a
> program that can't do multi-threading, such as Matlab.
>   
You could do something like this:
* Write a new osmosis task that accepts data input, but throws an 
exception when the required number of ways is reached.
* Write a wrapper application that calls osmosis repeatedly with 
reducing bounding box sizes until osmosis completes successfully.

But again, I may have misunderstood your question because this sounds 
like a bad way of solving the problem.
> It seems to me that it would be very easy to add an "if" loop to the
> end of the osmosis main loop and cause it to end early. For instance
> (in Matlab code, because that's what I know best):
>
> %if no argument for resultLimit, set resultLimit = 0.
>
> if resultLimit~=0
>   if numResults >= resultLimit
>   break;
> end
>
> Is this reasonable? I thought it could be initially implemented as an
> undocumented feature. If I were to ask for this to be looked at soon,
> would that be too much? Normally I would like to do this kind of thing
> myself, but for Java I really have no clue.
>   
If I understand the problem correctly then this is not something I would 
add to osmosis, there must be a better way of doing this.  If you must 
write something like this it would be better implemented as an 
application that uses osmosis as a library and adds its own custom 
tasks.  But I'll do my best to help you get started or help you find an 
alternative way of solving the problem.  As I mentioned earlier, I need 
to understand what you're trying to achieve because I think others will 
have already solved the problem in different ways.

Brett