[OSM-dev] Osmosis bug when using 'completeWays' option?

[Lambertus]

80n Thanks for helping.

Downloaded all 200 bboxes and I'm afraid this won't fly. It takes about 1 - 3 minutes before each download completes (varies greatly). In total it took about 4 hours to download The Netherlands... Parsing the planet file takes about 1.5 to 2 hours.

I also noticed that the osmxapi does not specify the amount of data it's going to return although it seems to fetch the data first before it starts sending. Maybe something to add....?
  ----- Original Message ----- 
  From: 80n 
  To: Lambertus 
  Cc: dev at openstreetmap.org 
  Sent: Sunday, December 02, 2007 13:35
  Subject: Re: [OSM-dev] Osmosis bug when using 'completeWays' option?


  On Dec 2, 2007 12:27 PM, Lambertus <osm at na1400.info> wrote:

    A few questions about that:
    - Does that include ways crossing the bbox boudaries? Osmosis has the tendency to 'forget' ways that have only one node into the bbox, that's why I was trying the 'completeWays' option. This results in 'gaps' between bboxes when converted to Garmin images.

  As long as there is at least one node in the bbox then you should get the way.  If there are no nodes in the bbox (for example, when a way just crosses a corner) then it will not give you the way. 
   
    - I need lot's of small bboxes. Currently about 200 for The Netherlands only, but expanding to 'the world' when I feel that the maps are production ready. Can the osmxapi handle that? I think that, in the long run, I'll need to fall back to a local copy to do all the work on...

  Yes.  As far as I know the only limiting factor is the apache timeout (currently set to about 20 minutes).  If this becomes a practical problem it should be possible to increase that limit. 
   
  80n



    About the latest planet; I could start patching that with daily/weekly dumps which would suffice for my needs.
      ----- Original Message ----- 
      From: 80n 
      To: Lambertus 
      Cc: dev at openstreetmap.org 
      Sent: Sunday, December 02, 2007 13:14
      Subject: Re: [OSM-dev] Osmosis bug when using 'completeWays' option?


      Lambertus
      You might find that this would also do what you need:

      wget http://www.informationfreeway.org/api/0.5/map?bbox=3.15,50.65,3.6,51.1 -O extract/63240001.osm

      Probably a bit quicker and probably more current than the latest planet.

      80n




      On Dec 2, 2007 11:07 AM, Lambertus < osm at na1400.info> wrote:

        When trying to extract a number of bounding boxes from the planet file using 
        Osmosis I run into a problem with the 'completeWays' option:
        Everything works well until I add the completeWays option. Osmosis fails to
        write the data to the output directory (which is on a separate harddisk) but 
        instead something starts using all the space on my root disk. It is not an
        .osm file as updatedb & locate can't find any stray ones. The whole process
        runs way longer that normal and finally dies when it runs out of disk space. 
        When the process dies the space on the disk is not released, that happens
        only after a reboot.

        Is this a bug or does the completeWays option invoke some sort of buffering?

        Below is an example of my Osmosis command (reduced to only one output for 
        clarity), both the 'planet/' and 'extract/' directories are on a separate
        disk:

        java -Xmx1048m -jar utils/osmosis/osmosis.jar
        --read-xml enableDateParsing=no file="planet/planet-latest.osm "
        outPipe.0="planet"
        --tee inPipe.0="planet" outputCount=1 outPipe.0="t1"
        --bounding-box completeWays=yes inPipe.0="t1" left=3.15 bottom=50.65
        top=51.1 right=3.6 outPipe.0= "bb1"
        --write-xml inPipe="bb1" file="extract/63240001.osm"



        _______________________________________________
        dev mailing list
        dev at openstreetmap.org 
        http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev




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