Task #2212

MIWP-8 (A) Conditions applying to access and use

Added by Michael Östling almost 6 years ago. Updated about 5 years ago.

Status:SubmittedStart date:16 Sep 2014
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Proposed change or action:

Description

This section has now been locked for editing and a draft version have been moved into the draft document.
See page:
https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/DraftVersionsMIWP-8
Further discussions and comments should be done on the draft

Conditions applying to access and use is now implemented in a way not in line with EN ISO 19115:2005. The task is to see what actions can be taken to handle this. Can the TG be updated to handle better alignment with EN ISO 19115:2005 and in the same time not giving to much problems for existing metadata records. The implication if not doing this is that Inspire MD is not compatible with other ISO19115 implementations. The task is to give suggestion on possible update on how to handle this. The task is related to Issue C. *Wiki:* https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/MIWP-8_(A)_Conditions_applying_to_access_and_use

Paper for access and use wiki MIWP-8.doc (17.5 KB) Marc Leobet, 19 Dec 2014 11:11 am

comparing FR and DE TG.doc (18.5 KB) Marc Leobet, 19 Dec 2014 11:45 am

History

#1 Updated by Michael Östling over 5 years ago

  • Description updated (diff)

#2 Updated by Michael Östling over 5 years ago

  • Description updated (diff)

#3 Updated by Michael Östling over 5 years ago

  • Description updated (diff)

NOTE - GEOSS Core is currently reviewing its profile for inclusion of Conditions on use and it may be usful to harmonise INSPIRE and GEOSS consistenly as possible. What they propose is  here:

http://twiki.geoviqua.org/twiki/bin/view/AIP6/LicenseISO

( Michael Ö: This is based on ISO19115-1 which we currently probabaly will not implement. But it is interesting to see how they now can  describe licenses in a more flexible way using new version of ISO19115.)

#4 Updated by James Reid over 5 years ago

Actually, GEOSS were agnostic to which flavour of 19115 as I asked them that question directly - although I guess its implied from their suggestions that its the 19115-1 flavour..

#5 Updated by Martin Seiler over 5 years ago

To provide useLimitation/useConstraints in compliance with ISO 19115 and to fullfil the INSPIRE TG we aggreed to provide the information in a redundant way in the German SDI. You can see an example here:

https://gist.github.com/anonymous/e378119231035010b5e9#file-gistfile1-xml

#6 Updated by Marc Leobet over 5 years ago

Dear all,

sorry to share with you lately this point about acces and use. I give in the attached file the FR answers to the questions asked in the related wiki

As an abstract, we started from the INSPIRE requirements, with the will to be at the same time compliant with ISO, and we took into account the feedbacks from regional implementations to add 6 use cases, covering all the possible cases (that is, more than the really encountered cases, see Security constraint).

I do not think usefull to copy here the technical references from the FR TG, that is Xpath ISO 19115XML example, but I could do it if you think usefull

#7 Updated by Marc Leobet over 5 years ago

To Martin Seiler : we have many differences between us. I made a table just to show side by side our recommandations to help the study.

Ffor what we understood in France, the information "Use Limitation: This dataset is not not to be used for navigation. " has to be made under MD_Constraint>useLimitation and not under MD_LegalConstraint>useLimitation

For data with fees, we have some diffrences with your guidelines (accessConstraints vs useConstraints. We consider that the licence is a first step to get the data when you have to pay for it. It is of course true for its use, but we developp more and more double licences and it looked more appropriate to do so.

I note that you have twice « fees apply », under two different tags.

 

#8 Updated by Marc Leobet over 5 years ago

For Geraldine Nolf, about the Flanders (BE) paper in the wiki page :

I note the same inversion than with DE between MD_Constraints & MD_LegalConstraint.

Under the expertise of ISO experts in IGN-F, our understanding of ISO 19115 is that MD_Constraints hold no legal value, except very specific use cases, where the responsability of the producers could be engaged in case of errors. Because of international conventions, it is limited to air and sea navigation.

Just to be sure that we understood the same thing under "national security and so on", I would like to precise that the codelist for MD_securityConstraints is understood as strictly related to military uses, as ISO 19115 was first draft for NATO uses. We think it is not adapted to describe the legal restriction for public access in INSPIRE, following art. 13 of INSPIRE directive, even "public security" where we do not use that (military) classification to protect information. The exception is an extremely short list concerning "essential places for the Nation".

Finally, I feel usefull to share with you that the first FR TG was under this form. The implementation experience led us to add XML examples because, as we see just above between French and German understanding of ISO, it was not sufficient for developpers. The result was the association, for a same word in the interface, to a different code in the XML and a different result for queries. So we decided to push interoperability through code recommandations and not only through textual ones.

best regards

LBT

 

#9 Updated by Martin Seiler over 5 years ago

Marc Leobet schrieb:

for what we understood in France, the information "Use Limitation: This dataset is not not to be used for navigation. " has to be made under MD_Constraint>useLimitation and not under MD_LegalConstraint>useLimitation For data with fees, we have some diffrences with your guidelines (accessConstraints vs useConstraints.  

Note for me / the group: We should recheck the ISO 19115 modelling here again, as I recall it holds quite some potential for confusion in this part.

 

 

#10 Updated by Marc Leobet over 5 years ago

Sure! That's an usual limit of interoperability. A critical issue, I guess.

#11 Updated by Michael Östling over 5 years ago

It seems we have two main solutions for this issue and I'm not sure the best way to continue here.
I have written some comments so I see if we have understood our various implementatiosn correctly.


Three steps we should run to solve put some light on this:
A How have we solved this in current national implementations (this is what we have done).

B IF starting from a blank sheet, how should these sections be written now ?
   Just so we see that we have same understanding on how the ISO 19115 model actually should be used.

and then finally
C What alternatives can we see in updating TG Metadata and maybe make updates in existing metadata.

 

A comment on the the alternative solutions.
I have tried to understand how its implemented in countries that have documented their solutions here (DE,FR,BE).
When checking the alternatives described I could see the following possible solutions for solving this
when looking into the current situation we have in our national implementation in Sweden.
This is just a way to describe how I understand your solutions above in wiki.

A
We handle pure technical limitations in metadata (not suitable for navigation) at
gmd:resourceConstraints/gmd:MD_Constraints/gmd:useLimitation

and 2.9.2 Conditions applying to access and use are handled at
gmd:resourceConstraints/gmd:MD_LegalConstraints/gmd:useLimitation


Since current technical guidelines checks at the following xpath
identificationInfo[1]/*/resourceConstraints/*/useLimitation
Any of the two above nodes would be accepted in Inspire GeoPortal.

It would be free for any country to use any of the two xpaths, but for thoose who want to separate
the two types useLimitations this could be possible. It would still be accepted to use
gmd:resourceConstraints/gmd:MD_Constraints/gmd:useLimitation

 

B

An other way to hande it would to be manage 2.9.2 Conditions applying to access and use in the element (where I would have placed it in first place)
gmd:MD_LegalConstraints/gmd:useConstraints
                                       gmd:otherConstraints/gco:CharacterString/"Use Constraints: Fees apply according to [...] "

And then in our Virtual CSW node (specific for Inspire harvesting) make a transformation of the information in xpath
                                       gmd:otherConstraints/gco:CharacterString/"Use Constraints:*"
and put a copy of that text into the element
gmd:resourceConstraints/gmd:MD_LegalConstraints/gmd:useLimitation
or
gmd:resourceConstraints/gmd:MD_MDConstraints/gmd:useLimitation

during harvesting. Then the copied text does not have to handled manually but are in right place when Inspire parses metadata.
(Of course handling the copied information manually is also valid for Inspire)


Both of the above solutions could work in parallell.




 

#12 Updated by Martin Seiler over 5 years ago

Michael Östling schrieb:

gmd:otherConstraints/gco:CharacterString/"Use Constraints: Fees apply according to [...] " And then in our Virtual CSW node (specific for Inspire harvesting) make a transformation of the information in xpath                                        gmd:otherConstraints/gco:CharacterString/"Use Constraints:*"

In order to do this you also need to have

<gmd:MD_RestrictionCode codeList="..." codeListValue="otherRestrictions" />

 

 

#13 Updated by Ine de Visser over 5 years ago

we use MD_Constraints/gmd:useLimitation to fullfil 2.9.2. A codelist with language neutral codes should be helpfull to harmonise the multiple writing methods of "no limitations"

we use gmd:MD_LegalConstraints/gmd:accessConstraints and gmd:otherConstraints to fullfil 2.9.1, where we use now two otherConstraints elements to document the status and the lisence (or the licence statement free for use) see current XML sniplet.

It should be nicer to use the anchor element for this to combine the statement  and the link as in the second XML sniplet

current situation;

<gmd:resourceConstraints>
<gmd:MD_Constraints>
<gmd:useLimitation>
<gco:CharacterString>Applications for which the data is not appropriate or no limitations</gco:CharacterString>
</gmd:useLimitation>
</gmd:MD_Constraints>
</gmd:resourceConstraints>
<gmd:resourceConstraints>
<gmd:MD_LegalConstraints>
<gmd:accessConstraints>
<gmd:MD_RestrictionCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#MD_RestrictionCode" codeListValue="otherRestrictions"/>
</gmd:accessConstraints>
<gmd:otherConstraints>
<gco:CharacterString>http://creativecommons.org/publicdomain/mark/1.0/deed.nl</gco:CharacterString>
</gmd:otherConstraints>
<gmd:otherConstraints>
<gco:CharacterString>no limitations</gco:CharacterString>
</gmd:otherConstraints>
</gmd:MD_LegalConstraints>
</gmd:resourceConstraints>

 

proposed change;

<gmd:resourceConstraints>
<gmd:MD_LegalConstraints>
<gmd:accessConstraints>
<gmd:MD_RestrictionCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#MD_RestrictionCode"
codeListValue="otherRestrictions"/>
</gmd:accessConstraints>
<gmd:otherConstraints>
<gmx:Anchor xlink:href="http://services.rce.geovoorziening.nl/www/GeoGedeeld_AMK_20111101.pdf">Geo gedeeld licentie</gmx:Anchor>
</gmd:otherConstraints>
</gmd:MD_LegalConstraints>
</gmd:resourceConstraints>

#14 Updated by Marc Leobet over 5 years ago

I strongly support the Ine's proposal: "A codelist with language neutral codes should be helpfull to harmonise the multiple writing methods of "no limitations" "; It would help machine-to-machine communication.

Could I propose the same for "open data" (as open data are often under an open licence, with few obligation (e.g. paternity), but it is a licence? Under ISO 19115 it is impossible to distinguish an open licence from a restricting licence.

#15 Updated by Peter Kochmann over 5 years ago

As far as I understood ISO 19115, there's no difference in expressing useLimitation via MD_Constraints (alone) or included in MD_LegalConstraints (together with accessConstraints and/or useConstraints and maybe otherConstraints). Therefore the given Path identificationInfo[1]/*/resourceConstraints/*/useLimitation covers both as Michael mentioned before.

To have a different use depending on "fitness for use" (MD_Constraints) or INSPIRE (MD_LegalConstraints) won't work in our catalogue system, because the software offers the element useLimitation only once. And useLimitation will always be put in MD_LegalConstraints.

#16 Updated by Marc Leobet over 5 years ago

I think consensus is unreachable on this topic : we have understood that fields under different way and it is too late to come back to an hypothetic general agreement.

That is why I am fond of Michael's proposal #11 : it let each MS free of its understanding, and a way to get European harmonisation.  

#17 Updated by Peter Kochmann over 5 years ago

When I looked up the issue of "Restrictions related to the access and use" in SDS I got aware of the following:

The examples for that issue given in TG SDS (chapter 4.6.4) show something interesting: in contrast to the existing TG metadata the restrictions on SDS are put in ISO-element otherConstraints (that's the place where they are designated to be following ISO) and not in ISO-element useLimitation (where TG metadata put them).

So maybe this is the (necessary) attempt to have a correction of this?

The discussion in this ticket on hand went on how to address useLimitation. I missed the discussion on how to find a way for the future to use useConstraints/accessConstraints togehter with otherConstraints instead!

#18 Updated by Michael Östling over 5 years ago

I don't see the real difference here Peter, could you elaborate.
The example in 4.6.4  (TG SDS V 3.1) shows both the use of
UseLimitation ("Conditions applying to access and use" )
and
OtherConstraints.  ("Limitations on public access")

Do you mean the reference to a Creative commons license written in the element "Limitations on public access"
<gmd:otherConstraints>
     <gco:CharacterString>Creative Commons - Attribution 3.0 Unported</gco:CharacterString>
</gmd:otherConstraints>

According to TG Metadata references to licenses should be in  "Conditions applying to access and use"
That is different as I understand it 

 

The IR also states that these restrictions should be

The technical restrictions applying to the access and use of the spatial data service shall be documented in the
metadata element “CONSTRAINT RELATED TO ACCESS AND USE” set out in Regulation (EC) No 1205/2008.

I see this as in addition to handle legal restrictions we shall also document technical restrictions on SDS.

I would suggest that Technical restrictions should only go into UseLimitation.


I do not see any simple way out here to solve this...

 

#19 Updated by Peter Kochmann over 5 years ago

Maybe I've drawn the wrong conclusions with this issue. So I'm afraid I have to recall my statement #17.

I read the example in TG SDS 4.6.4 like that for SDS there's the opportunity to have "conditions applying to access and use" in ISO element accessConstraints/otherConstraints (where it is designated by ISO to be) and not to be bound to have it in useLimitation (like TG Metadata says by now).

Reality is that "Restrictions related to the access and use" with SDS are required to be documented in "CONSTRAINT RELATED TO ACCESS AND USE set out in IR Metadata". And behind that we still have "Conditions applying to access and use" (TG Metadata 2.9.2) and "Limitations on public access" (TG Metadata 2.9.1).

Sorry for causing confusion! I had the hope that we could find a way to have an end of the misinterpretation of useLimitation and the Mapping in TG Metadata 2.9.2 (what I consider to be wrong).

#20 Updated by Martin Seiler over 5 years ago

Marc Leobet schrieb:

I think consensus is unreachable on this topic : we have understood that fields under different way and it is too late to come back to an hypothetic general agreement. That is why I am fond of Michael's proposal #11 : it let each MS free of its understanding, and a way to get European harmonisation.  

Well Marc, even if we accept this situation, we should propose a recommended way to do this.

#21 Updated by Martin Seiler over 5 years ago

Ine de Visser schrieb:

 <gmx:Anchor xlink:href="http://services.rce.geovoorziening.nl/www/GeoGedeeld_AMK_20111101.pdf">Geo gedeeld licentie</gmx:Anchor> </gmd:otherConstraints>

The gmx:Anchor element seems to be very useful here. What would that mean for existing implementations?

 

#22 Updated by Martin Seiler over 5 years ago

Michael Östling schrieb:

B An other way to hande it would to be manage 2.9.2 Conditions applying to access and use in the element (where I would have placed it in first place) gmd:MD_LegalConstraints/gmd:useConstraints                                        gmd:otherConstraints/gco:CharacterString/"Use Constraints: Fees apply according to [...] " And then in our Virtual CSW node (specific for Inspire harvesting) make a transformation of the information in xpath                                        gmd:otherConstraints/gco:CharacterString/"Use Constraints:*" and put a copy of that text into the element gmd:resourceConstraints/gmd:MD_LegalConstraints/gmd:useLimitation or gmd:resourceConstraints/gmd:MD_MDConstraints/gmd:useLimitation during harvesting. Then the copied text does not have to handled manually but are in right place when Inspire parses metadata. (Of course handling the copied information manually is also valid for Inspire) Both of the above solutions could work in parallell.  

The approach with a "virtual CSW node" makes quite assumptions on the (national?) INSPIRE/SDI architecutre, no? I thnik we would need a solution without dependencies to SDI-architecture here.

#23 Updated by Michael Östling over 5 years ago

I have gone through the Directive again and tried to understand what we really need to solve.
This is just an effort to see how it could be solved  without any relations to the existing TG

The below should be seen as a suggested  parallel implementation that could be equally valid as the current
implementation. So a member-state could continue with existing implementation in TG MD v1.3
or use this additional alternative to be more in line with ISO 19115.
Would that be possible ? To have two parallell implementations allowed ?
I have not included the Security-classfication.

I would assume there could be arguments also against this solution so I just made a short intro to lift the discussion.

I must admit I'm not 100% sure I have fully seen the details but as I see it we have the following.

 

Article 5.2.b

Metadata shall include information on the following:
conditions applying to access to, and use of, spatial data
sets and ser vices and, where applicable, cor responding fees;

 

Article 11.2.f
conditions applying to the access to and use of spatial data
sets and ser vices;

These could include Access or Use restrictions of Both types restrictions

Article 13

By way of derogation from Ar ticle 11(1), Member States may
limit public access to spatial data sets and ser vices through the
ser vices refer red to in points (b) to (e) of Ar ticle 11(1), or to the
e-commerce ser vices refer red to in Ar ticle 14(3), where such
access would adversely affect any of the following:

This is also a Access-restriction but for a specifc target group "The Public"


Could we handle this by adding  a ResourceConstraintsScope for restrictions?

Conditions applying to access and use should be implemted as the ISO 19115 suggest with
a UseRestriction and/or a AccessRestriction depending on the actual situation.

A Use constraint

or a Access constraint

 

Limitations on public access is also a Access constraint but for a specific target group.
A possibility could be to define various target groups for constraints such as Public, Academic and Commercial and describe these in the registry like the  URL
below. In this case I have used a gmx:anchor to set a scope for the AccessConstraints that is described in the OtherConstraints.

 

Other scopes like Commercial could be added.

 

 

We could also add the specific AccessConstraints in the registry as it is defined in the Directive.

 

With the above implementation I should be simple (I think) for the Inspire Geoportal to extract the metadata needed to fulfil the requirements.
 

 

#24 Updated by Michael Östling over 5 years ago

Would it be acceptable in technical guidelines to accept two alternative implementations of this element?


Where an implementer must select either of these two for metadata.

That a metadata record can either handle Conditions applying to access and use in accordance with current technical guidelines or
according to an alternative implementation eg as outlined above using an Anchor to define the "Scope" for the restriction.

Then any implementation can choose to keep the current implementation or manage this element more closely according to ISO 19115.

The Inspire Geoportal has in this case to check if a record contains implementation according to new TG or current TG.

 

 

#25 Updated by Peter Kochmann over 5 years ago

--> Conditions applying to access and use:

I think I would agree to an alternative solution if it was strongly recommended and maybe flagged as "the future way". So existing metadata and catalogue implementations could be converted little by little.

But I'm not sure if this is in line with article 11 of INSPIRE regulation demanding this information to be an argument of a discovery service. How will this work when there can be several places?

The alternative solution itself in my opinion would always demand MD_LegalConstraints. We discussed the issue "MD_Constraints or MD_LegalConstraints?" before and said that both ways would be o.k. From now on this would only apply to the "old" solution.

 

--> Limitations on public access:

I don't think that there's a requirement to document the target group of the access constraint. I guess this would be optional, right? I think of the efforts for adjusting the catalogue systems on this ...

 

--> INSPIRE Testing / Geoportal / ATS:

Do we need a decision criterion that says whether the conditions applying to access and use are placed in ISO according to TG Metadata 1.3 or (following the alternative solution) in TG Metadata 2.0?

#26 Updated by Marc Leobet over 5 years ago

Thank you Michaël to open a new door.

First, the easiest answer : we can propose two alternative implementations if we are in position to achieve an European interorability, ie. to propose a way to understand the metadata from Finland - or Norway ;-) - to Greece. That is what we decided for data interoperability, for example : standardisation for data sharing. But that is the same that to define a future unique profile, I guess.

Your proposal for Conditions applying to access and use fits well with our views : your proposal is adapted to manage open data and data under commercial licence.
The first would have to be under "UseConstraint" (there is no access constraint), the second under "access Constraint". Could we imagine to include such use cases in the future TG?

For Limitations on public access, we thought that it would be easier to take the "sort of codelist" established by art. 13 instead of trying to imagine new classification (commercial and so on). But we have not got the idea of an anchor : it could be the good key to go on.

Peter highlights a very good question through art. 11 : users need to know that conditions. May be the proposals from Michaël could help software to bring good answers?

 

 

#27 Updated by Michael Östling over 5 years ago

Peter Kochmann wrote:

--> Conditions applying to access and use: I think I would agree to an alternative solution if it was strongly recommended and maybe flagged as "the future way". So existing metadata and catalogue implementations could be converted little by little. But I'm not sure if this is in line with article 11 of INSPIRE regulation demanding this information to be an argument of a discovery service. How will this work when there can be several places? The alternative solution itself in my opinion would always demand MD_LegalConstraints. We discussed the issue "MD_Constraints or MD_LegalConstraints?" before and said that both ways would be o.k. From now on this would only apply to the "old" solution.   --> Limitations on public access: I don't think that there's a requirement to document the target group of the access constraint. I guess this would be optional, right? I think of the efforts for adjusting the catalogue systems on this ...   --> INSPIRE Testing / Geoportal / ATS: Do we need a decision criterion that says whether the conditions applying to access and use are placed in ISO according to TG Metadata 1.3 or (following the alternative solution) in TG Metadata 2.0?

Good question Peter, on Article 11.
But when reading on the other elements that should be queryable. Some of them are multiple elements I would think:
eg:
11.2.b classification of spatial data and services
Here you will need to query both Service Type and Service Classification

11.2.c the quality and validity of spatial data sets
Here you also need to query a number of queryables to get full info.

So if we in TG specify two queryables to find everything on

11.2.f  conditions applying to the access to and use of spatial data
sets and ser vices;

I might think we still fulfill Article 11 (but I'm out on thin Ice here)

 

 

--> Limitations on public access:
The reason for using the Target scope here is to differentiate an General Access Conditions from Access Constraints for the Public.
If a Access constraint is added without the TargetScope it is a General Condition applying to Access

 

--> INSPIRE Testing / Geoportal / ATS:
I would here suggest that if TargetScope is used then the Conditions applying to Access and use and Limitations on Public access is according
to TG Metadata 2.0

But a general comment on the suggestion to use some kind of TargetScope. Its just a way to find some new ideas.
Maybe this is not the optional but it may open discussions again...

#28 Updated by Marc Leobet over 5 years ago

After our meeting, I tried to adapt existing FR recommandations to our conclusions. Please feel free to share comments on it. :

Use of useConstraint element, example for an open data licence :

Technical reference

XML example

<gmd:resourceConstraints>
<gmd:MD_LegalConstraints>
<gmd:useConstraints>
<gmd:MD_RestrictionCode codeList=http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/gmxCodelists.xml#MD_RestrictionCode codeListValue="licence">licence</gmd:MD_RestrictionCode>
</gmd:useConstraints>
<gmd:useConstraints>
<gmd:MD_RestrictionCode codeList=http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/gmxCodelists.xml#MD_RestrictionCode codeListValue="licence">otherRestrictions</gmd:MD_RestrictionCode>
</gmd:useConstraints>


<gmd:otherConstraints>
<gco:CharacterString>obligation to mention the owner and the date of the dataset - Open licence 1.0 http://ddata.over-blog.com/xxxyyy/4/37/99/26/licence/Licence-Ouverte-Open-Licence-ENG.pdf</gco:CharacterString>
</
gmd:otherConstraints>
</gmd:MD_LegalConstraints>
</
gmd:resourceConstraints>

 Use of AccessConstraint element, example for data with fees :

Technical reference

XML example

<gmd:resourceConstraints>
<gmd:MD_LegalConstraints>
<gmd:accessConstraints>
<gmd:MD_RestrictionCode codeList=http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/gmxCodelists.xml#MD_RestrictionCode codeListValue="licence">licence</gmd:MD_RestrictionCode>
</gmd:accessConstraints>
<gmd:accessConstraints>
<gmd:MD_RestrictionCode codeList=http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/gmxCodelists.xml#MD_RestrictionCode codeListValue="otherRestrictions">otherRestrictions</gmd:MD_RestrictionCode>
</gmd:accessConstraints>
<gmd:otherConstraints>
<gco:CharacterString> The access and use are subject to the conditions described on the site: http://<name><pageConditionUtilisation></gco:CharacterString></gmd:otherConstraints>
</gmd:MD_LegalConstraints>
</
gmd:resourceConstraints>

 

Case of limitation of public access (position of bears in the Pyrenees, restricted under Art. 13.1.h : the protection of the environment to which such information relates, such as the location of rare species.)

Technical reference

XML example

<gmd:resourceConstraints>
<gmd:MD_LegalConstraints>
<gmd:accessConstraints>
<gmd:MD_RestrictionCode codeList=http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/gmxCodelists.xml#MD_RestrictionCode codeListValue="restricted">restricted</gmd:MD_RestrictionCode>
</gmd:accessConstraints>
<gmd:accessConstraints>
<gmd:MD_RestrictionCode codeList=http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/gmxCodelists.xml#MD_RestrictionCode codeListValue="otherRestrictions">otherRestrictions</gmd:MD_RestrictionCode>
</gmd:accessConstraints>
<gmd:otherConstraints>
<gco:CharacterString>Directive 2007/2/CE (INSPIRE), Article 13.1.h </gco:CharacterString>
</gmd:otherConstraints>
</gmd:MD_LegalConstraints>
</
gmd:resourceConstraints>


 

 

 

#29 Updated by Michael Östling about 5 years ago

  • Description updated (diff)

Also available in: Atom PDF