Roads, Transit, LINZ, NZOGPS
rediguana
The recent effort with Transit's data has had me thinking about how we
handle bringing in data from various different sources.
One of my big concerns with importing LINZ or NZOGPS road data is that
it will overwrite existing data already stored as vectors within OSM.
NZOGPS, in particular, as it is an often changing dataset, will also
need to be reimported on a regular basis (e.g. monthly/quarterly) to
provide updates. How then, are we intending to manage the repeated
merging of multiple datasets (LINZ, NZOGPS) into existing data in a
non-destructive manner? We should be ensuring that existing data is
not deleted during the import process. How would we manage
discrepancies between OSM, LINZ and NZOGPS data if they are all
different?
I've had a couple of offlist discussions about this in recent days,
and at least as an intermediary step until such time as a process is
nailed down, I'm wondering if the initial approach should be to
convert LINZ and NZOGPS vector nodes to trackpoints and import them.
By importing as trackpoints they won't overwrite any existing data
(non-destructive import), and they will complement other tracklogs
already in the system. Additionally, no single dataset will be
dominant over others. This will also provide a nice stopgap until such
time as more detailed GPS tracklogs are available.
The main downsides to this approach would appear to be:
* roads that have few vertices will not render very well as
trackpoints
* vectors for roads have to be manually created.
Do we know if LINZ is prepared to release NZTopoOnline downloads as
CCAttributionShareAlikeNZ? If so, we could look at trialling the
conversion of LINZ roads to trackpoints, and handling them in a
similar fashion to Transit's data.
Cheers Gav
Ed
under a CC-Attribution license.
http://koordinates.com/category/topographical/?s=s
Gavin Treadgold
Great - thank's Ed. I'll have a look at that once I've got the Transit
data out of the way.
Cheers Gavin
Hamish
> The recent effort with Transit's data has had me thinking about how we
> handle bringing in data from various different sources.
>
> One of my big concerns with importing LINZ or NZOGPS road data is that
> it will overwrite existing data already stored as vectors within OSM.
> NZOGPS, in particular, as it is an often changing dataset, will also
> need to be reimported on a regular basis (e.g. monthly/quarterly) to
> provide updates. How then, are we intending to manage the repeated
> merging of multiple datasets (LINZ, NZOGPS) into existing data in a
> non-destructive manner? We should be ensuring that existing data is
> not deleted during the import process. How would we manage
> discrepancies between OSM, LINZ and NZOGPS data if they are all
> different?
see previous screenshot re. discrepancies between LINZ(v4)+Transit.
fyi there is currently a parallel thread going on on the OSGeo GeoData
mailing list with regard to how to incorporate the new US TIGER road
data into OSM.
http://lists.osgeo.org/pipermail/geodata/2008-June/date.html
A reasonable idea there was to create a diff map of what has been
updated, then audit that by hand instead of bulk replacement /
reimport. That is so OSM user corrections are not lost whenever a new
(uncorrected) dataset comes out.
> I've had a couple of offlist discussions about this in recent days,
> and at least as an intermediary step until such time as a process is
> nailed down, I'm wondering if the initial approach should be to
> convert LINZ and NZOGPS vector nodes to trackpoints and import them.
> By importing as trackpoints they won't overwrite any existing data
> (non-destructive import), and they will complement other tracklogs
> already in the system. Additionally, no single dataset will be
> dominant over others. This will also provide a nice stopgap until such
> time as more detailed GPS tracklogs are available.
not a bad idea. note that it removes some of the drive to load the
full LINZ data into OSM, complete with road names, 1-way-streetness,
etc.
> The main downsides to this approach would appear to be:
> * roads that have few vertices will not render very well as
> trackpoints
I don't know if gpsbabel has a non-timestamp filter for it, but that
is easily corrected for in GRASS GIS:
"v.to.points -v dmax=<max dist between vertices>"
> * vectors for roads have to be manually created.
if points are sequential, a "pack + sdistance split" like previously
mentioned for gpsbabel could do the trick in a starting from raw data
way.
> Do we know if LINZ is prepared to release NZTopoOnline downloads as
> CCAttributionShareAlikeNZ? If so, we could look at trialling the
> conversion of LINZ roads to trackpoints, and handling them in a
> similar fashion to Transit's data.
The entire LINZ dataset can be purchased for under $300 or so, and
then you may relicense it as you wish. (past their very generous
license)
If I understand correctly, the good people at Koordinates have already
offered to distribute their copy under the same terms as LINZ. (but
don't quote me on that)
Hamish