So... (I guess this is mainly addressed to those cunning people who have managed importing other LINZ data) what will it take to get this address data imported to OSM?
Regardless, it will be interesting to see how the AIMs release interplays with NZFSC's looooong standing position on licensing. If - somehow - locality information remains under the current license, we can't use that data for any OSM purpose.
suburb_locality varchar 80 Dannemora Suburb/Locality from the NZ Localities (NZ Fire Service owned dataset).
town_city varchar 80 Auckland Town/City from the NZ Localities (NZ Fire Service owned dataset).
Assuming no schema change, will the transition from Beta just mean some added/deleted/modified records that bring the data up to some quality standard, with most records remaining unchanged. Or a more wholesale re-release with new ids?
Trying to get an idea of what happens if I use this data now,...
And got this reply
Just to confirm, no schema change will be made. This layer will have its 'Beta' tag removed and over written by the latest data, therefore, more of a wholesale re-release.
Address_ids will change only if they have been updated since this layer has been up, as we are carrying over Landonline's IDs.
On Friday, 4 December 2015 15:49:55 UTC+13, Hamish Campbell wrote:Regardless, it will be interesting to see how the AIMs release interplays with NZFSC's looooong standing position on licensing. If - somehow - locality information remains under the current license, we can't use that data for any OSM purpose.
Interesting. The following is a quote from "LINZ Data Service: Street Address Data Dictionary (Beta) v2.0"suburb_locality varchar 80 Dannemora Suburb/Locality from the NZ Localities (NZ Fire Service owned dataset).
town_city varchar 80 Auckland Town/City from the NZ Localities (NZ Fire Service owned dataset).
But the data is already being published by LINZ as Creative Commons Attribution 3.0 New Zealand
so anyone can use it without any contact with the nzfs
The NZFS can't own the name itself, so what does "NZ Fire Service owned dataset" even mean in this contex?
So basically we can reverse engineer the NZFS dataset from the LINZ dataset and the parcel dataset (NZFS boundaries are snapped to parcel boundaries.
So yeah - tons we can do but we need some people to make it happen. Some people who have geo skillz. I'm not sure that the existing community has the bandwidth at the moment? Would it be worth doing a one day OSM hack event to kick start some of this?
--
You received this message because you are subscribed to the Google Groups "nzopengis" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nzopengis+...@googlegroups.com.
To post to this group, send email to nzop...@googlegroups.com.
Visit this group at https://groups.google.com/group/nzopengis.
For more options, visit https://groups.google.com/d/optout.
To unsubscribe from this group and stop receiving emails from it, send an email to nzopengis+unsubscribe@googlegroups.com.
To post to this group, send email to nzop...@googlegroups.com.
Visit this group at https://groups.google.com/group/nzopengis.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "nzopengis" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nzopengis+unsubscribe@googlegroups.com.
>(although there will be some objection
Can you expand on why there will be some objection? From who?
> we need to update what fields we put on the actual items.
?
> But we will need to cover how we do merges with existing data, whether
> we add the address to the building (I would keep them as separate
> points, there is precedence for this in some countries).
I have made a number of suggestions about some of these aspects in this
very thread - do you have any comments on those?
--
There is no question that it is a good idea to get these addresses is. It is just the process that needs to be followed and refine.I can tell you from personal experience that you have to tread _very_ carefully with the imports list. ;-)
Mapping a country's addresses is not impossible, it is just difficult
and a lengthy task. Urban areas are relatively fast mapped if the
number of mappers per 1000 inhabitants is similar to some well known
countries in Central Europe. The lengthy part is mapping rural areas
where the distances between the settlements are large. If you want to
strengthen your urban communities, you should only import addresses in
rural areas. (This does not mean that you have to wait until urban
areas are finished)
To anticipate some questions.We already have specific approval from LINZ:
* The source data is CC-BY, and the attribution requirements are well
documented.
- What's the purpose of adding LINZ:address_id=* and linz:change_id=*
to OSM?
- You propose to add a tag source:revision=*. Where will it be placed?
On the changeset or on the imported objects?
- You write on the wiki page that you are not sure whether to use
addr:city=*, addr:place=* or addr:hamlet=* for the field "town_city" of
the LINZ data. Why are you not sure? Is town_city a mix of information
which should be stored in two distinct fields in an ideal dataset or
are you unsure about the definitions of the three OSM tags?
- Have you assessed the quality of the data by checking it on the
ground on a few locations in urban and rural areas?
- The wiki page should be improved by adding more technical details of
the import, namely how duplicates will be detected and which
software/workflow will be used to upload the data. Please publish the
source code of the scripts if you use any (at a sufficient location for
source code).
- Please add a list of user accounts who will upload the data. Their
user profiles at openstreetmap.org should mention who they belong to.
One import account should only be used by one natural person.
Although you write that your import proposal is in an early stage, you
have already started uploading data. https://www.openstreetmap.org/chan
geset/49492831 Please wait at least one week in addition whether
further concerns are raised. Please read the Import Guideline
carefully! I doubt that you haven't read it as carefully as necessary
to do a good import. (Btw, it is a very good idea to read most emails
of the last six months in the archive of this mailing list, too)