# data from website
CITY="Boston_MA"
wget -N --progress=dot:mega \
"http://download.osgeo.org/livedvd/data/osm/$CITY/$CITY.osm.bz2"
bunzip2 $CITY.osm.bz2
mv $CITY.osm web_$CITY.osm
#using xapi
CITY="Boston_MA"
# BBOX info from https://github.com/OSGeo/OSGeoLive/blob/d5fda583fd240459cf435ec107aa5baf0b13ce51/bin/install_osm.sh#L102
BBOX="-71.16528,42.31628,-70.99396,42.39493"
XAPI_URL="http://www.overpass-api.de/api/xapi?"
XAPI_EXTRA="[@meta]"
wget --progress=dot:mega -O "$CITY.osm" \
"${XAPI_URL}*[bbox=$BBOX]$XAPI_EXTRA"
#bunzip2 $CITY.osm.bz2
#bzip2 "$CITY.osm"
mv $CITY.osm xap_$CITY.osm
ls -la
I get:
79090054 Jun 11 13:03 web_Boston_MA.osm
148090502 Jun 25 11:27 xap_Boston_MA.o
visual proof
Roads generated with web_Boston_MA.osm
Roads generated with xap_Boston_MA.osm
Consequences
Using the OSGeo live V11:
Option 1) When using OSGeo Live
OSGeo Live comes with osm data from the city of Boston.
CITY="Boston_MA"
cp ~/data/osm/$CITY.osm.bz2 .
bunzip2 $CITY.osm.bz2
Option 2) Download data form OSGeo Live website
The exact same data can be found on the OSGeo Live download page.
CITY="Boston_MA"
wget -N --progress=dot:mega \
"http://download.osgeo.org/livedvd/data/osm/$CITY/$CITY.osm.bz2"
bunzip2 $CITY.osm.bz2
Is no longer TRUE
For pgRouting purposes: the gid on the ways table will be different for the same osm_id.
Worth to mention that @woodbri has plans for the 2 weeks before FOSS4G so the workshop writing should be finished at least 3 weeks before the FOSS4G so we have at least 1 week for refining details.
WORSE case
If OSGeo live final release leaves in inconsistent state the BBOX. (Which means that the BBOX on the install_osm.sh is inconsistent with http://download.osgeo.org/livedvd/data/osm/Boston_MA/Boston_MA.osm.bz2.
)
Solution:
Create in pgRouting documentation a Download directory and store the Boston_MA.osm.bz2 that corresponds to the BBOX that OSGeo live install_osm.sh
And use that link instead of referencing the http://download.osgeo.org/livedvd/data/osm/Boston_MA/Boston_MA.osm.bz2
I think it's OK to wait for a more stable release of OSGeo Live.
Since the relevant workshop documentation is online availaable we could theoretically fix things until the last minute ;-)
Downloading the data from the download website http://download.osgeo.org/livedvd/data/osm/Boston_MA/ and using the BBOX on https://github.com/OSGeo/OSGeoLive/blob/d5fda583fd240459cf435ec107aa5baf0b13ce51/bin/install_osm.sh#L102 give different areas
Proof
proof by script
I get: 79090054 Jun 11 13:03 web_Boston_MA.osm 148090502 Jun 25 11:27 xap_Boston_MA.o
visual proof
Roads generated with web_Boston_MA.osm
Roads generated with xap_Boston_MA.osm
Consequences
Using the OSGeo live V11:
Is no longer
TRUE
gid
on theways
table will be different for the sameosm_id
.Which is a stopper, out of our control, for writing the workshop. Maybe the BBOX in https://github.com/OSGeo/OSGeoLive/blob/d5fda583fd240459cf435ec107aa5baf0b13ce51/bin/install_osm.sh#L102 gets changed (lots of changes are still happening even on the alpha version). Maybe wait for beta releases, or in the worse case, wait until the final release, before continuing working on the workshop for Boston.
Worth to mention that @woodbri has plans for the 2 weeks before FOSS4G so the workshop writing should be finished at least 3 weeks before the FOSS4G so we have at least 1 week for refining details.
WORSE case
If OSGeo live final release leaves in inconsistent state the BBOX. (Which means that the BBOX on the install_osm.sh is inconsistent with
http://download.osgeo.org/livedvd/data/osm/Boston_MA/Boston_MA.osm.bz2
. )Boston_MA.osm.bz2
that corresponds to the BBOX that OSGeo live install_osm.shAnd use that link instead of referencing the
http://download.osgeo.org/livedvd/data/osm/Boston_MA/Boston_MA.osm.bz2