LINZ

From OpenStreetMap Wiki
Jump to: navigation, search

For information on the Austrian city, please see Linz Austria.

LINZ (Land Information New Zealand) is the NZ government department which is responsible for creating and holding information concerning land ownership. They have data for all of New Zealand's roads, released under a license which is compatible with that of OSM.

They also maintain data on other features, which is of interest to OSM. Work on incorporating this data is also underway.

Please see NZ for general information on all imports.

This data could be used within Openstreetmap and provide a very high level of detail/completeness for the whole of New Zealand.

As of 2011-08-23, LINZ gave their consent to use the new licensing terms: 

Further to my phone call yesterday, this email is to confirm that LINZ gives permission to re-license our LDS CC-by data under OSM’s 
new terms and licences for the purposes of third parties wishing to contribute to the OSM database.

As of 2008-03-18, LINZ gave their consent to include, modify and derive LINZ data in OSM with suitable attribution.

 Apologies for the delay - after gaining advice from our legal team we have concluded
 that you are able to use the information providing that you use the following clause
 for inclusion with the data that is supplied:
  
 " Contains data sourced from Land Information New Zealand. Crown Copyright reserved.
 Land Information New Zealand gives no warranty in relation to the data, including its
 accuracy, reliability and suitability and accepts no liability whatsoever in relation
 to any loss, damage or other costs relating to the use of any data, any compilations,
 derivative works or modifications of the data"

There are currently (2010-03) discussions to use further LINZ datasets; more information will be made available as it is known.


Contents

Status 

[ August 2011 ]

[ June 2011 ]

With the Chathams are done we are working on the NZ mainland.

The JOSM Validator plugin is a good place to start.

Completed so far

Data License

"Contains data sourced from Land Information New Zealand. Crown Copyright reserved. Land Information New Zealand gives no warranty in relation to the data, including its accuracy, reliability and suitability and accepts no liability whatsoever in relation to any loss, damage or other costs relating to the use of any data, any compilations, derivative works or modifications of the data".

This approval has been submitted to the legal-talk list, requesting a suitable technical solution for displaying the note where applicable.

The general consensus so far on OSM seems to be that attribution will be:

OSM License change to ODBL

OSM are more than likely going to change their license to ODBL

If this goes ahead (tentatively early-2011, but this may blow out), we have been advised to ask LINZ again for their permission to distribute their data under the new license.

Method 1: JR

(for more see below)

Method 2: RC

(for more see below)

Overview

Underway

(for more see below)

bbox=-177,-44.5,-175.5,-43.5

TODO

bbox=157.5,-59.0,179.5,-25.5

How to help

see the LINZ/Howto wiki page for some tips on getting started.
(page is currently still a work in progress)

Key people

This list is in progress. Feel free to add yourself, e.g. for any particular area, even as an expert for a particular geographic zone (for checking merging)


LINZ (NZOGPS) to Openstreetmap import

NZOGPS road data

LINZ topo v16 data

These are 166 vector map layers covering everything from topographic contour lines to waterfall positions to power pylons to high resolution vector coastline. A full set of roads and railways for the country are included. Basically these layers are everything that they use create the 1:50,000 printed topo maps.

License is BSD-like with attribution, see Crown Copyright statement above.

Cadastral boundary imports

Any people particularly interested and/or know about the existing datasets, please put your names here

-- which datasets in particular were you thinking about? Property boundaries + house numbers? Regional council borders?


Some other public domain shapefile data is available from the statistics office: http://www.stats.govt.nz/methods_and_services/access-data/geographical-boundaries.aspx http://www.stats.govt.nz/publications/businessperformanceenergyandagriculture/download-digital-boundaries.aspx


"Copyright
Information obtained from Statistics New Zealand may be freely used, reproduced, or quoted unless otherwise specified. In all cases Statistics New Zealand must be acknowledged as the source."

Geographic area volunteers

(north to south)

Primarily people who would like to be involved in merging of the data in any particular area

North Island

South Island

Data import

Datasets

See LINZ data sets for more information
Old NZMG 2.5m res. orthophotos can be georegistered using their topo map bounds (see .csv file on website). Adjust bounds by 1/2 a cell to correct for grid vs. cell-centre convention.
Marco in Italy has all the NZ nautical charts registered in BSB format as part of the kapgen project. (GDAL can read BSB)

Areas

("bbox" is short for "bounding box", and is given in x for degrees longitude and y for degrees latitude. Southern and Western hemispheres get a negative sign. Thus bbox=west,south,east,north bounds)
OSM will not export data across the international date line in one blob - these need to be extracted as two separate pieces, and joined together (or not, as needs) at a later point. The Chatham Islands are on the opposite side of this line to the rest of New Zealand.

bbox=157.5,-59.0,179.9,-25.5
bbox=171.90,-41.75,178.70,-33.95
bbox=166.3,-46.68,174.48,-40.31


bbox=-177,-44.5,-175.5,-43.5
bbox=-176.373,-44.450,-175.973,-44.115


bbox=167.25,-47.34,168.31,-46.66
bbox=175.2,-36.4,175.6,-36
bbox=174.98,-36.8525,175.206,-36.7186

Method

Mark I: Joe Richard's custom mp2osm.py

Joe will fill this in shortly (2009-09-15). Code is here 

http://trac.openstreetmap.org/browser/applications/utils/import/linz2osm/mp2osm_linz_jr.py

the resulting XML OSM files are available here: 

http://joerichards.dev.openstreetmap.org/files.html

The old-dev server comparorator is now at: (mostly working again) 

http://joerichards.dev.openstreetmap.org/index-new.html

Mark II: Rob Coup's LINZ-2-OSM web app

April 2010

(helpers can ask on the nzogps mailing list or contact User:Rcoup at robert@coup.net.nz for a login)
The base web app code can be found at linz2osm in github.

Tools

Comparison maps

http://www.nztopomaps.com
http://www.topomap.co.nz
http://joerichards.dev.openstreetmap.org/index-new.html

QA maps

Stats

Scripts

Bridges

or

Place names

Trial import to OSM development server

User:JoeRichards has carried out a test import, using a dev server rather than the live osm data. information on the import is at this link: LINZ Trial Import

Generic OSM API v0.6 dev server for trial uploads: api06.dev.openstreetmap.org

Live OSM server data import

A trial import was carried out on 2010-03-27 by Glen Barnes, Andrew Coup and Robin Paulson.

The Area selected was the Chatham Islands, because:

The data source was the raw dataset from LINZ, as NZOGPS data does not include the Chatham Islands.
The data was made available in ArcGIS shape file (.shp) format. OSM cannot deal with these files, so a converter, shp2osm, had to be used.
Shp2osm requires a rules file, to map the parameters in the shape file to corresponding parameters in the osm file

Tags used

(See eventual LINZ-2-OSM's data_dir.xml file for the latest authoritative list)


All layers

[link to the attribution page on the wiki, with the required attribution page required by LINZ]
[link to the relevant page for this dataset, on the LINZ website]
[the version of the data set we have imported; currently V16]

Some LINZ-specific tags were also created, to tie in with LINZ attributes which are not required by OSM, but which will enable the data to be updated more easily:

Roads

[this is what is used in OSM when the type of highway is unknown]
[the surface of the road - the LINZ data sepcifies one of three surface types; there are several more in OSM, so the closest three were chosen]
[this tag was only used for roads without a road_name_id tag; it was (wisely) assumed these roads may not be for public access]
[a 13 digit unique number; one is given by LINZ to every road in NZ]

Troubleshooting

Stale tiles

If you only edit a tag and not the base spatial data the slippy tile may not get marked as dirty and so Mapnik won't know to rebuild it. If that happens you can right-click on the osm.org OpenLayers canvas and 'view image' to view just the one tile. then in the address bar add /status to the end of the png's URL to see the last time it was rebuilt. add /dirty to the end of the URL to get it rebuilt the next time someone views it. (There will be a slight delay lag before this happens, so be patient and you also probably have to bypass your web browser's cache (shift-reload) to see the new version). /dirty is only meant for limited development debugging, use sparingly.

"Leaky" Osamarender tiles

While trying to clean up some Coastline I notice that in osm.org's Osmarender that some tiles are "flooded". In a manual audit + JOSM's Validation tool I don't find any obvious errors, but perhaps I missed something. The osm.nl coastline checker seems to be offline since last April and the osm.org Mapnik coastline is too long out of date to be useful feedback. I read somewhere that for osm.org's Osmarender there is a file in svn somewhere which states which tiles are wet, which are dry, and which are mixed. Is there a way of seeing (maybe an OpenLayers overlay) what a particular tile is classified as? so then a request could be filed somewhere to get its wet/dry/mixed status updated? Or maybe it just takes a while for the renderers to sort themselves out?

examples of the breakage:

Fixing duplicate nodes between two layers

Some layers, like roads+tracks or fences+hedges will naturally connect be be provided in two separate source layers. Where they meet their nodes should be merged. The trick here is to only merge duplicate nodes between layers which really need it- for example connecting a road network to a fence line might lead to some unfortunate turn-by-turn direction routing one day!

Single key, multiple values

Using JOSM to download

(clustered features)

Using Xapi to download

(sparse features)

The Xapi download interface can be used with the wget program to download just the two layers we are interested in. Those can then be uploaded into JOSM and duplicates found using the JOSM Validator plugin, merge them, then upload the changes. The data in this example will be fences and hedges in the Chatham Islands. 

wget -O chatham_hedges_and_fences.osm \
 "http://osmxapi.hypercube.telascience.org/api/0.6/way[barrier=hedge|fence][LINZ:source_version=V16][bbox=-177,-44.5,-175.5,-43.5]"
If way layers are already uploaded you must re-download them from the server.
Fixing with the Validator
TODO
Verify tags are preserved (eg gate nodes into roadways)
This may take care of a bunch of other Validation warnings. So start on the duplicate nodes first, then re-validate!

Xapi takes a while to get updates from the main data server, so when using it you need to wait a little while before re-downloading something you've just uploaded.

Multiple keys

This is the same as above but you have to run Xapi twice and import each .osm file individually. If merging nodes to ways (for example gates to roads) it might be possible to proceed with only the roadways already uploaded (untested). If that works it will be the preferred method.

If you try and merge two layers not yet uploaded to the main server it is likely that the upload will get confused if it tries to modify nodes on the server which do not exist yet. In these cases you might export the locally modified .osm files to a new merged one, then close JOSM and then reopen with the new single merged .osm file. Then upload that. (untested, and more dangerous). Generally to aid with fixing mistakes you will want to upload the raw data in one step, then fix it in another. That way if the fix has to be reverted it is possible to do so. (aka "atomic commits").

Undoing uploads 

 wget -O changeset_4593253.osm \
    "http://osmxapi.hypercube.telascience.org/api/0.6/*[@changeset=4593253]"

Be quick! If anything has changed since the upload this is likely to break.

Fixing bulk tagging mistakes after upload

(try not to get here) 

wget -O chatham_access_unknown.osm \
 "http://osmxapi.hypercube.telascience.org/api/0.6/*[access=unknown][LINZ:source_version=V16][bbox=-177,-44.5,-175.5,-43.5]"

See the Xapi help page for information on how to make more complex or specific queries.

After the dance

- TopOSM example
- TopOSM/Details
- TopOSM_howto
(but if you are just after pretty contour lines and hill shading, and don't really care about road names too much, you might as well just use gdal2tiles.py to convert the LINZ NZTopo50 300dpi GeoTiff raster scans of the topo sheets into a WMS/TMS server and save yourself a lot of trouble...)
OSM on Paper

Previous discussions and notes

Retrieved from "http://wiki.openstreetmap.org/wiki/LINZ"
Personal tools
Namespaces
Variants
Actions
site
Toolbox