- From: Joshua Lieberman <jlieberman@tumblingwalls.com>
- Date: Fri, 22 Jul 2016 18:18:41 -0400
- To: Byron Cochrane <bcochrane@linz.govt.nz>
- Cc: Jeremy Tandy <jeremy.tandy@gmail.com>, Andrea Perego <andrea.perego@jrc.ec.europa.eu>, Linda van den Brink <l.vandenbrink@geonovum.nl>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>, "Little, Chris" <chris.little@metoffice.gov.uk>
Byron, I agree that WGS84 is probably the most interoperable CRS, as long as it doesn't devolve into plat carré with distances calculated in degrees. Josh Sent from my iPhone > On Jul 22, 2016, at 5:59 PM, Byron Cochrane <bcochrane@linz.govt.nz> wrote: > > Also the choice of CRS is, in the cartographic community, an aesthetic one that I would think web designers would want to use more if it were easier and they knew how. Displaying the northern US border as a curve rather than a straight line can make the presentation of your information easier to read. These are the sort of choices that designers make every day in other aspects of a web page. Enabling designers to more easily make these same type of choices in display of cartographic information will greatly improve the utility of web maps in general. Choice of CRS is a basic design best practice. > > I concur that there is also a strong localisation issue. This most often in my experience occurs when using external mapping data from the web in combination with local data on a desktop app. The local data is often not in WGS 84 for a variety of reasons. The ability to consume these external data in a compatible CRS is very useful in this case. > > All that being said, I do agree that serving your geospatial data in 4326 by default should be best practice. > > Cheers, > Byron > ________________________________________ > From: Joshua Lieberman [jlieberman@tumblingwalls.com] > Sent: Saturday, July 23, 2016 1:42 AM > To: Jeremy Tandy > Cc: Andrea Perego; Linda van den Brink; public-sdw-wg@w3.org; Byron Cochrane; Little, Chris > Subject: Re: DWBP SDWBP alignment notes > > As long as they are linked. It is useful and sometimes not easy to obtain for a given map extent the valid projected CRS alternatives for a given level of geoid conformance, or vice-versa. > > Josh > > On Jul 22, 2016, at 7:45 AM, Jeremy Tandy <jeremy.tandy@gmail.com<mailto:jeremy.tandy@gmail.com>> wrote: > > If we mention it in both places would that be enough? Jeremy > On Fri, 22 Jul 2016 at 12:43, Joshua Lieberman <jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>> wrote: > By far the greatest proportion of CRS's are projected. Some of these pertain to a locale, such as US State Plane but the larger number are regional with varying faithfulness to the geoid away from their medians, such as UTM. This peculiarly a geospatial issue, as are cumulative projection errors, so there is a data quality aspect, but I'm not sure that either locale or data quality covers the issue completely. > > Josh > > Joshua Lieberman, Ph.D. > Principal, Tumbling Walls Consultancy > Tel/Direct: +1 617-431-6431 > jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com> > > On Jul 22, 2016, at 06:18, Jeremy Tandy <jeremy.tandy@gmail.com<mailto:jeremy.tandy@gmail.com>> wrote: > > Hi all. Looks like we have consensus emerging :-) ... I'm happy to see CRS as locale info given what you've said. Jeremy > On Fri, 22 Jul 2016 at 11:09, Andrea Perego <andrea.perego@jrc.ec.europa.eu<mailto:andrea.perego@jrc.ec.europa.eu>> wrote: >> On 22/07/2016 11:45, Linda van den Brink wrote: >> Responding to the comments on SDWBP 8… >> >>> SDWBP 8 is about when to use a specific CRS rather than rely on the ubiquitous EPSG 3857 / WGS 84; which is a data quality issue. I don't see > how this is a locale issue? >> >> Intuitively, and probably this is because I don’t have a spatial >> background originally, I do see it as a locale issue. These specific CRS >> exist to provide a coordinate system for a specific region of the world >> (often a specific country). Someone from France is never going to use >> the Dutch coordinate system and vice versa. It’s region-specific, like a >> language, thus I’m thinking ‘locale’. > > I think the notion of 'locale' is a good approximation, and it is > domain-independent enough to make non-geo experts have a (partial) > understanding of what a CRS is. > >> And yes, you could see it as a data quality thing as well, because these >> specific CRS exist for high accuracy spatial data, but that is something >> only spatial people know. > > +1. This can be seen as conformance of data with a "standard" - in this > case, a (spatial or temporal) reference system. This is how you can > model it with DQV. And this is how it is modelled in GeoDCAT-AP. > > Andrea > > >> *Van:*Byron Cochrane [mailto:bcochrane@linz.govt.nz<mailto:bcochrane@linz.govt.nz>] >> *Verzonden:* woensdag 20 juli 2016 13:53 >> *Aan:* 'Jeremy Tandy'; 'Little, Chris'; 'public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>' >> *Onderwerp:* RE: DWBP SDWBP alignment notes >> >> >> >> …and reply to 30 >> >> >> >> *From:*Jeremy Tandy [mailto:jeremy.tandy@gmail.com<mailto:jeremy.tandy@gmail.com>] >> *Sent:* Wednesday, 20 July 2016 1:51 a.m. >> *To:* Little, Chris; Byron Cochrane; public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org> >> <mailto:public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>> >> *Subject:* Re: DWBP SDWBP alignment notes >> >> >> >> I forgot SDWBP 29 and 30 ... >> >> >> >> SDWBP 29. Agreed. >> >> >> >> SDWBP 30. I recall Bill Roberts saying that being able to use the API to >> search was important. I think that DWBP 23 covers the broad issue of >> APIs, but we should (at least) use a search API as an example? >> >> So a spatial specific search API to cite for within a dataset would be >> useful. At the dataset level we have some spatial search api tools >> (GeoSPARQL, CSW). Not so sure about a bp to cite for inside a spatial >> api. Good idea, though >> >> >> >> OK, That's me done for now. >> >> >> >> On Tue, 19 Jul 2016 at 14:45 Jeremy Tandy <jeremy.tandy@gmail.com<mailto:jeremy.tandy@gmail.com> >> <mailto:jeremy.tandy@gmail.com<mailto:jeremy.tandy@gmail.com>>> wrote: >> >> Responding now to Byron. >> >> >> >> Thanks for the assessment. Comments below... >> >> >> >> SDWBP 3 is about converting dataset-scoped identifiers to URLs. I >> don't see how this relates to vocabularies (topic of DWBP 15). >> Please can you elaborate? >> >> >> >> SDWBP 8 is about when to use a specific CRS rather than rely on the >> ubiquitous EPSG 3857 / WGS 84; which is a data quality issue. I >> don't see how this is a locale issue? >> >> >> >> SDWBP 9. Agreed. Are you aware of any 'vocabularies' that can be >> used to describe relative positions? (other than GML) >> >> >> >> ... same question applies to SDWBP 10; what are the vocabularies for >> representing positional inaccuracy? >> >> >> >> SDWBP 13 is trying to say "if you know about a [spatial] >> relationship with another resource (and you care enough to write it >> down) then write it down; don't rely on spatial correlation" ... >> which is why I aligned it with SDWBP 23. The discussion on which >> spatial vocabulary to use to express those relationships was SDWBP >> 12 'use spatial semantics for spatial things'. >> >> >> >> SDWBP 14-18. Agree; we need to make sure that folks interested in >> environmental data (observations) are adequately covered. My hope >> was that the SSN work would provide sufficient examples. Also, it's >> difficult for us to define "best practice" for these cases that will >> refer to the _brand new_ SSN redux (!). Our BPs need to be based on >> evidence of real world application. >> >> >> >> SDWBP 19-22. I like your idea of giving a primacy to "linking data" >> ... BP: "do linked data" (!) >> >> >> >> SDWBP 24-25 ... I can see your point about overlap with DWBP 1-7. >> When writing SDWBP 24 I was trying to emphasise that the Links (that >> we'd earlier recommended creating) can be used to find / discover >> data; so more about maximising value of Linked Data than talking >> about particular types of metadata. SDWBP 25 is about allowing >> search engines to see inside the dataset. I'd taken DWBP 1-7 as >> focusing on the dataset-level metadata rather than the individual >> entities described by the dataset. Looking again at DWBP 1, I see >> that that is not necessarily the case. Given that, it would make >> sense to extend DWBP 1; e.g. using schema.org<http://schema.org/> <http://schema.org<http://schema.org/>> >> and hypercat as examples? >> >> >> >> SDWBP 26; agree that this is coverage in DWBP 2 >> >> >> >> SDWBP 27. This is similar to providing subsets; but the emphasis was >> to get get data owners to publish their data how ever they could. If >> they could only afford to do bulk publication, then that's good. If >> they can provide a rich API, even better. Either way, I think we >> cover the nuances of this elsewhere. >> >> >> >> SDWBP 28. Agree that this isn't spatial specific. I think the DWBP >> folks did a great job of covering the bases with DWBP 23 'make data >> available through an API' that I thought we might have to. Likewise, >> SDWBP 29 aligns well with DWBP 25 'Provide complete documentation >> for your API'. >> >> >> >> On Tue, 19 Jul 2016 at 13:52 Jeremy Tandy <jeremy.tandy@gmail.com<mailto:jeremy.tandy@gmail.com> >> <mailto:jeremy.tandy@gmail.com<mailto:jeremy.tandy@gmail.com>>> wrote: >> >> Hi Chris. >> >> >> >> Thanks for taking the time to look at this. >> >> >> >> Responding to (some of) your points about >> "expansion/restriction/explanation/examples/prescription of DWBP >> best practices probably needed"... >> >> >> >> DWBP 1 and DWBP 2. I think that generally, when we think about >> dataset metadata (e.g. for discovery) as defined by, say, DCAT >> or ISO 19115 I think that this fits in DWBP 2 "Provide >> descriptive metadata". Looking at ISO 19115-1, this does include >> CRS (as 'referenceSystemInfo'; type 'MD_ReferenceSystem'). >> Don't know if this is in GeoDCAT-AP. That said, we also need to >> cover use of CRS / SRS in the data itself. I think that's >> covered in DWBP 15 (reuse vocabularies). We might look at >> including that as part of the 'data quality' information (DWBP >> 7) which says "Data quality might seriously affect the >> suitability of data for specific applications" ... which is also >> applicable to CRS. >> >> >> >> DWBP 4. You make a good point; this practice enables someone to >> conveniently query or explore the dataset. Is this inherently >> spatial? As of now, I'm not sure where in our set of examples I >> could add this. Thoughts appreciated. >> >> >> >> DWBP 11. We talk about "use URIs as identifiers within >> datasets"; these are for the things described in datasets (e.g. >> spatial things, geometries etc.) so that they can be referenced >> from _outside_ the dataset. This should resolve your >> intra-dataset concern. >> >> >> >> DWBP 14. providing different resolutions / matrix tile sets >> (etc.) fits better with DWBP 18 'provide subsets of large >> datasets'. I see a reduced resolution dataset as a "subset". >> >> >> >> DWBP 28. I think this is a different use of the word "coverage". >> What this is referring to is trying to make sure that the >> "dataset" includes all the reference material that is required >> to interpret the data when you take it offline for archive. This >> isn't a spatial thing. >> >> >> >> Thanks again for the input. >> >> >> >> Jeremy >> >> >> >> On Thu, 14 Jul 2016 at 10:53 Little, Chris >> <chris.little@metoffice.gov.uk<mailto:chris.little@metoffice.gov.uk> >> <mailto:chris.little@metoffice.gov.uk<mailto:chris.little@metoffice.gov.uk>>> wrote: >> >> Jeremy, Linda, >> >> >> >> To add to Byron’s useful comments here is my take on what >> DWBPs can be left untouched/unqualified and which may need >> more prescriptive additions. I have left in the current >> numbering as these are direct links to the current Candidate >> Recommendation document. I have tried to be strict – we >> could easily have meaningful comments on each of the 35 BPs. >> >> >> >> I think that there is a significant amount of work to do >> this properly. >> >> >> >> A. BPs to leave as is, as just point to BP in DWBP section: >> >> Best Practice 3 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#LocaleParametersMetadata>: >> Provide locale parameters metadata >> >> Best Practice 5 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#DataLicense>: >> Provide data license information >> >> Best Practice 6 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#DataProvenance>: >> Provide data provenance information >> >> Best Practice 8 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#VersioningInfo>: >> Provide a version indicator >> >> Best Practice 9 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#VersionHistory>: >> Provide version history >> >> Best Practice 10 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#UniqueIdentifiers>: >> Use persistent URIs as identifiers of datasets >> >> Best Practice 12 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#VersionIdentifiers>: >> Assign URIs to dataset versions and series >> >> Best Practice 16 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#ChooseRightFormalizationLevel>: >> Choose the right [vocabulary/semantic] formalization level: >> this already has an example of supplying coordinates of bus >> stops as well as times and route numbers of buses >> >> Best Practice 19 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#Conneg>: >> Use content negotiation for serving data available in >> multiple formats >> >> Best Practice 20 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#AccessRealTime>: >> Provide real-time access >> >> Best Practice 21 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#AccessUptoDate>: >> Provide data up to date >> >> Best Practice 22 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#DataUnavailabilityReference>: >> Provide an explanation for data that is not available >> >> Best Practice 23 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#useanAPI>: >> Make data available through an API: Unless there are some >> specific ones to recommend >> >> Best Practice 24 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#APIHttpVerbs>: >> Use Web Standards as the foundation of APIs >> >> Best Practice 25 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#documentYourAPI>: >> Provide complete documentation for your API >> >> Best Practice 26 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#avoidBreakingChangesAPI>: >> Avoid Breaking Changes to Your API >> >> Best Practice 27 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#ResourceStatus>: >> Preserve identifiers >> >> Best Practice 29 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#GatherFeedback>: >> Gather feedback from data consumers >> >> Best Practice 30 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#FeedbackInformation>: >> Make feedback available >> >> Best Practice 31 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#EnrichData>: >> Enrich data by generating new data >> >> Best Practice 32 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#ProvideComplementaryPresentations>: >> Provide Complementary Presentations >> >> Best Practice 33 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#ProvideFeedbackToPublisher>: >> Provide Feedback to the Original Publisher >> >> Best Practice 34 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#FollowLicensingTerms>: >> Follow Licensing Terms >> >> Best Practice 35 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#CiteOriginalPublication>: >> Cite the Original Publication >> >> >> >> B. Additional >> expansion/restriction/explanation/examples/prescription >> probably needed >> >> Best Practice 1 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#ProvideMetadata>: >> Provide metadata: Some preferences like geo extensions to >> dcterms, or ISO19115 >> >> Best Practice 2 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#DescriptiveMetadata>: >> Provide descriptive metadata:Does this include CRSs? >> >> Best Practice 4 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#StructuralMetadata>: >> Provide structural metadata: Does this include map layer >> model? Tiling matrix sets? 3D City geometry? >> >> Best Practice 7 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#DataQuality>: >> Provide data quality information:Suggest that this includes >> CRSs and expected accuracy and precision? >> >> Best Practice 11 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#identifiersWithinDatasets>: >> Use persistent URIs as identifiers within datasets: Not sure >> about this – many intra-dataset URIs may involve coordinates >> that may need special URI handling? >> >> Best Practice 13 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#MachineReadableStandardizedFormat>: >> Use machine-readable standardized data formats: Suggest some? >> >> Best Practice 14 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#MultipleFormats>: >> Provide data in multiple formats: Suggest that this might >> cover different resolutions/matrix tile sets? >> >> Best Practice 15 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#ReuseVocabularies>: >> Reuse vocabularies, preferably standardized ones:Are there >> any to suggest? >> >> Best Practice 17 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#BulkAccess>: >> Provide bulk download:Suggest some examples of where this >> could be useful, as opposed to incremental updating >> >> Best Practice 18 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#ProvideSubsets>: >> Provide Subsets for Large Datasets: Suggest tiling, both of >> maps and data like 3DCity. >> >> Best Practice 28 >> <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#EvaluateCoverage>: >> Assess dataset coverage:Is this just a bounding box? >> Completeness of tile sets? Certificate of Quality? OWS Context? >> >> >> >> HTH, Chris >> >> *From:*Byron Cochrane [mailto:bcochrane@linz.govt.nz<mailto:bcochrane@linz.govt.nz> >> <mailto:bcochrane@linz.govt.nz<mailto:bcochrane@linz.govt.nz>>] >> *Sent:* Wednesday, July 13, 2016 11:52 PM >> *To:* 'public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org> <mailto:public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>>'; >> 'Jeremy Tandy' >> *Subject:* DWBP SDWBP allignment notes >> >> >> >> Hi Jeremy, >> >> >> >> Here are the notes I made reviewing the two BP docs as >> promised. I have not had time time adjust much to the >> feedback last night. My approach was to review your BP >> Consolidation Proposal notes and add comments. Mostly, I >> generally agreed with your existing comments so you can >> assume general agreement with those BPs not commented on >> here. Notes are still very rough and need further thought, >> but provide me a starting point. Not sure all these notes >> agree with each other yet! >> >> >> >> SDWBP 3 - This would more naturally fit in reuse of existing >> vocabularies discussion (DWBP 15?). Important point is when >> to make spatial relationships explicit or leave implicit >> >> >> >> SDWBP 8 - I am inclined to think DWBP 3 is the correct place >> to talk about this. Can recommend WGS 84 as default, but >> not convinced that this is just a “data quality” issue >> >> >> >> SDWBP 9 - Same as 3. Belongs in DWBP 15 >> >> >> >> SDWBP 13 - Seems very similar to 3 and 9 but not sure 23 is >> the place for this. >> >> >> >> SDWBP 14-18 - All of Sensors and Observations section. Need >> to think how to handle this. Do we lose something valuable >> that is not covered by SSN if we take this out? >> >> >> >> SDWBP 19-22 - Isn’t linked data an implicit goal of this and >> a specific need for DWBP? Or if these are needed for >> peculiarities of spatial, should these specifically link to >> related “BP for Publishing Linked Data” topics? >> >> >> >> SDWBP 24-26 - This section should align with DWBP 1-7 - the >> various forms of metadata BC 24 - Do not see how this >> differs from 3,9,13,23 BC 25 - Crawability of data is not a >> specific concern of spatial. Ideally if needed it should be >> in DWBP, but this is not possible. I have some strong >> disagreements with the perceived value of crawliblity when >> applied to data, but can leave that aside for the time being. >> >> >> >> SDWBP 26 - already covered in DWBP 2 ”spatial coverage”. >> For API guidance look to alignment with DWBP 25 >> >> >> >> SDWBP 27 - Isn’t this the same as providing subsets DWBP >> 11? Also, APIs are covered in DWBP 23 -26. Not sure what is >> that geo specific here >> >> >> >> SDWBP 28 - Most of this section is not Geo specific. Some >> out of date info here. WFS section needs a serious update >> to be with the times. As of OGC Testbed 11, WFS has a >> restful interface and has always been able to carry payloads >> other than GML. APIs are well covered generally in DWBP >> 23-26. Should align geo specific concerns with these >> >> >> >> SDWBP 29 - The examples section of “GetCapabilities” is >> useful. Topic is otherwise covered in DWBP API section. >> There has been much discussion in other venues about the >> need for a landing page that contains GetCapabilities info. >> >> >> >> SDWBP 30 - Again little specific to geo. Should be covered >> in DWBP? >> >> >> >> As I said these are rough notes. I hope to work more on >> these tomorrow and may begin to experiment with alignment >> with DWBP by topic (rather than number as suggested by >> Phil). Already seeing issue there such as in metadata >> section where spatial metadata generally covers many of the >> first few best practices. So a one to one alignment may be >> difficult without a great deal of repetition. >> >> >> >> Cheers, >> >> >> >> *Byron Cochrane >> **SDI Technical Leader* >> >> *New Zealand Geospatial Office* >> >> >> >> *E** bcochrane@linz.govt.nz<mailto:bcochrane@linz.govt.nz> >> <mailto:bcochrane@linz.govt.nz<mailto:bcochrane@linz.govt.nz>>| **DDI** **04 460 >> 0576| **M** **021 794 501* >> >> >> >> *Wellington Office, Level 7, Radio New Zealand House, 155 >> The Terrace >> PO Box 5501, Wellington 6145, New Zealand | **T**04 460 >> 0110 ** >> **W www.linz.govt.nz<http://www.linz.govt.nz/> <http://www.linz.govt.nz/> | >> data.linz.govt.nz<http://data.linz.govt.nz/> <http://www.data.linz.govt.nz/> * >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> This message contains information, which may be in >> confidence and may be subject to legal privilege. If you are >> not the intended recipient, you must not peruse, use, >> disseminate, distribute or copy this message. If you have >> received this message in error, please notify us immediately >> (Phone 0800 665 463 or info@linz.govt.nz<mailto:info@linz.govt.nz> >> <mailto:info@linz.govt.nz<mailto:info@linz.govt.nz>>) and destroy the original >> message. LINZ accepts no responsibility for changes to this >> email, or for any attachments, after its transmission from >> LINZ. Thank You. > > -- > Andrea Perego, Ph.D. > Scientific / Technical Project Officer > European Commission DG JRC > Directorate B - Growth and Innovation > Unit B6 - Digital Economy > Via E. Fermi, 2749 - TP 262 > 21027 Ispra VA, Italy > > https://ec.europa.eu/jrc/ > > This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or info@linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You. >
Received on Friday, 22 July 2016 22:19:32 UTC