Change proposals on the ir on data interoperability received from ms and eea/eionet contents



Yüklə 0,54 Mb.
səhifə3/8
tarix21.08.2018
ölçüsü0,54 Mb.
#73575
1   2   3   4   5   6   7   8

2.2Code-list related issues

2.2.1Change values and add three new values in code list "IUCNDesignationValue" 5.3.2.4.3.


Country /Issue number:

EEA-NSS1-1


Affected article / annex:

?/Annex I



Theme(s):

Protected Sites



Subject: change values and add three new values in code list "IUCNDesignationValue" 5.3.2.4.3.


Observations / problem description:

The current values in the code list "IUCNDesignationValue" are misleading and do not conform to the global standard use of the IUCN management categories. The use of the shortened versions of the definitions has the potential to be very misleading and to cause confusion. For instance, "nationalPark" is both part of a definition of an IUCN management category (II) and the name of a designation as defined by countries. Within scientific literature and regional and global databases (e.g the CDDA, the WDPA [World Database on Protected Areas] www.protectedplanet.net) the IUCN management categories are indicated using Roman Numerals.

reference: http://www.iucn.org/about/work/programmes/gpap_home/gpap_capacity2/gpap_pub/gpap_catpub/?13959/Guidelines-for-applying-protected-area-management-categories

http://www.unep-wcmc.org/resources-and-data/wdpa (see WDPA User Manual 1.1)

The same request for change is made from the WDPA (UNEP-WCMC) to the INSPIRE process. You can review the request at https://ies-svn.jrc.ec.europa.eu/issues/2562 and https://ies-svn.jrc.ec.europa.eu/issues/2565.


Proposed legislative change(s):
(including precise reference, current text and proposed amendment):


Rationale for change(s):
(including concrete implementation evidence)


Expected impacts (including benefits):

The INSPIRE code list will be in line with the owner of the code list, UNEP-WCMC and WDPA on behalf of the IUCN.

Changes needed for Annex C of D2.8.I.9 Data Specification on Protected Sites-Technical Guidelines

Changes to the codelist register

Since PS is an Annex I, most implementers have already created their dataset and relevant services.





TC facilitator evaluation: INSPIRE IUCN code list should conform to the global standard use of the IUCN management categories.
Kathi Schleidt: General: align the code list requirements in the IR with those stemming from the data specs! In EF all codelists are listed as extensibility:any, although this is only correct for 2 of the 7 codelists defined. Currently we’ve made the codelists available anyway, but the way it stands it is unclear to data providers what is actually required.



TC link(s):

2.2.2Extension of DesignationType code list. 5.3.2.2.1.


Country /Issue number:

EEA-NSS1-3


Affected article / annex:

?/Annex I



Theme(s):

Protected Sites



Subject: Extension of DesignationType code list. 5.3.2.2.1.

Observations / problem description:

Nationally designated areas (reported through the CDDA data flow) currently have no entry in the DesignationType code list. IUCN codes were supposedly meant to be used for that, but not all nationally designated areas have an IUCN category.



Proposed legislative change(s):
(including precise reference, current text and proposed amendment):

Add new value e.g. “cdda” or “nationalDesignation”


Rationale for change(s):
(including concrete implementation evidence)

Nationally designated areas that do not have (and will not have in the future) an IUCN code will currently have to void the siteDesignation.



Expected impacts (including benefits):

More protected sites can be provided correctly through INSPIRE Annex I.






TC facilitator evaluation: An extension of both the Designation SchemeValue and the DesignationValue code lists can be provided.

In the framework of the' CDDA in conformity with INSPIRE' project, the European Environment Agency has already provided an extension of both the Designation SchemeValue and the DesignationValue code list e.g. they added the value "cdda" to the  Designation SchemeValue code list and they extended the DesignationValue with the ProtectedAreaDesignationValue code list.




TC link(s): https://themes.jrc.ec.europa.eu/discussion/view/119293/extending-of-code-lists

2.2.3Code list EU_AirQualityReferenceComponentValue


Issue number: 3

Affected documents: IR

Themes: Atmospheric Conditions and Meteorological Geographical Features

Subject: Code list EU_AirQualityReferenceComponentValue


Description: The regulation does not define values for the EU_AirQualityReferenceComponentValue Code list defined by the section 13.2.1.1.of annex IV.

The Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services does not provide values for the EU_AirQualityReferenceComponentValue Code list.

The section 13.2.1.1 of annex IV shows:

Definitions of phenomena regarding air quality in the context of reporting under Union legislation.



The allowed values for this code list comprise any values defined by data providers.

Data providers may use the values specified in the INSPIRE Technical Guidance document on Atmospheric Conditions and Meteorological Geographical Features.’
In the INSPIRE registry, the code list is empty.

http://INSPIRE.ec.europa.eu/code list/EU_AirQualityReferenceComponentValue




Corrigendum:

We think it would be necessary that this section shows the allowed values for the UE_AirQualityReferenceComponentValue code list as a table with the name and definition of the value.






TC facilitator evaluation:

Fear we have got bugs on multiple levels here! First off, in the data spec, the location of this codelist is specified as http://www.eionet.europa.eu/aqportal/codelists (not the INSPIRE URI listed above). Based on the current status of EEA codelists, this should be changed to http://dd.eionet.europa.eu/vocabulary/aq/pollutant.

Then the real problem, the ObservableProperties are a bit strange as they end up describing the content of a codelist reference; in an ideal INSPIREd world the codelists for observable properties would be structured accordingly (but they probably would not be!). The EU_AirQualityReferenceComponentValue is referenced by part of this data structure, so at the end of the day will never be used.

Recommendation: Either we do some serious work on the ObservableProperties Model and see to it that it is properly implemented by the relevant codelist providers (EEA as well as other relevant organizations), or we just cut it and put in a recommendation to utilize well established codelists such as the EEA list mentioned above for this purpose.



TC link(s):

2.2.4Code list GRIB_CodeTable4_2Value


Issue number: 4

Affected documents: IR

Themes: Atmospheric Conditions and Meteorological Geographical Features

Subject: Code list GRIB_CodeTable4_2Value

Description: The regulation does not define values for the GRIB_CodeTable4_2Value Code list defined by the section 13.2.1.2.of annex IV.

The Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services does not provide values for the GRIB_CodeTable4_2Value Code list.

Section 13.2.1.2 of annex IV shows:

Definitions of phenomena observed in meteorology.



The allowed values for this code list comprise any values defined by data providers.

Data providers may use the values specified in the INSPIRE Technical Guidance document on Atmospheric Conditions and Meteorological Geographical Features.’

In the INSPIRE registry, the code list is empty.

http://INSPIRE.ec.europa.eu/code list/GRIB_CodeTable4_2Value


Corrigendum:

We think it would be necessary that this section shows the allowed values for the GRIB_CodeTable4_2Value code list as a table with the name and definition of the value.






TC facilitator evaluation:
This seems to be general policy issue regarding externally managed code lists. The Data Specifications for ACMF in Annex C provide a link to GRIB_CodeTable4_2Value as:

http://vocab.nerc.ac.uk/collection/I01/current/. It could be that the INSPIRE registry needs to be updated with this link.


Kathi Schliedt: Same issue as in 2.2.3 Code list EU_AirQualityReferenceComponentValue

Also goes for Base2: CFStandardNamesValue

All 3 specializations of ObservableProperties: PhenomenonTypeValue should probably be cut (together with the ObservableProperties); References to well-established codelists such as the following should be provided as recommendations:

AQ: http://dd.eionet.europa.eu/vocabulary/aq/pollutant

WMO: http://vocab.nerc.ac.uk/collection/I01/current/

OF: http://vocab.nerc.ac.uk/collection/P01/current/




TC link(s):

2.2.5Codelist ProcessParameterNameValue


Issue number: 5

Affected documents: IR

Themes: Atmospheric Conditions and Meteorological Geographical Features

Subject: Codelist ProcessParameterNameValue

Description: The regulation does not define values for the ProcessParameterNameValue Code list defined by the section 7.2.3.1 of annex I (annex I, section 7, Observation Model).

The Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services does not provide values for the ProcessParameterNameValue Code list.

The section 7.2.3.1 of Annex I shows:

A code list of names of process parameters.



The allowed values for this code list comprise any values defined by data providers.’
In the INSPIRE registry, the code list is empty.

http://INSPIRE.ec.europa.eu/code list/ProcessParameterNameValue




Corrigendum:

We think it would be necessary that this section shows the allowed values for the ProcessParameterNameValue code list as a table with the name and definition of the value.






TC facilitator evaluation:

There has been no discussion on the Thematic Clusters to provide a ProcessParameterNameValue code list. The current Data Specifications allows for any to be used. Accordingly, it would be good to understand the rationale as to why specifying a code list is necessary.

The ProcessParameter was designed to allow for the addition of relevant information on the measurement process. The ProcessParameterNameValue codelist has been specified with extensibility:any. This was done as it was clear that new concepts pertaining to the measurement process will arise, and must be accorded for.

Within D2.9, some values have been specified, i.e. “relatedMonitoringFeature” must be provided within the ProcessParameter name to stipulate the Sampling Point the observation was made at.

Recommendations: Some of the stipulations from D2.9 should be formalized as a codelist, as currently free text strings are being used/recommended. This should also be provided in a revised version of D2.9


TC link(s):

2.2.6Code list StatisticalFunctionTypeValue


Issue number: 6

Affected documents: IR

Themes: Atmospheric Conditions and Meteorological Geographical Features

Subject: Code list StatisticalFunctionTypeValue



Description: The regulation does not define values for the StatisticalFunctionTypeValue Code list defined by the section 7.3.3.2. of annex I. (annex I, section 7, Observation Model).

The Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services does not provide values for the StatisticalFunctionTypeValue Code list.

Section 7.3.3.2. of annex I shows:

A code list of statistical functions (e.g. maximum, minimum, mean).

The allowed values for this code list comprise any values defined by data providers.’
In the INSPIRE registry, the code list is empty.

http://INSPIRE.ec.europa.eu/code list/StatisticalFunctionTypeValue




Corrigendum:

We think it would be necessary that this section shows the allowed values for the StatisticalFunctionTypeValue Code list as a table with the name and definition of the value.






TC facilitator evaluation:

Same issue as above with the codelists EU_AirQualityReferenceComponentValue and GRIB_CodeTable4_2Value.

The ObservableProperties model should be revisited, a decision must be reached on if this should be followed up (truly implemented) or cut from the GCM (thus also cutting this codelist from the depths of the ObservableProperties model)


TC link(s):

2.2.7Code list defined in the Technical Guideline but undefined in Commission Regulation (EU) No 1089/2010


Issue number: 7

Affected documents: TG

Themes: Atmospheric Conditions and Meteorological Geographical Features

Subject: Code list defined in the Technical Guideline but undefined in Commission Regulation (EU) No 1089/2010.

Description:

In the section 5.3.3 Externally governed code lists in Document D2.8.III.13-14 Data Specification on Atmospheric Conditions and Meteorological Geographical Features:

There is a code list that does not appeared in the Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services (annex IV, section 13). It is the GRIB_CodeTable4_201Value.
This code list is not included in the implementation rule on Atmospheric Conditions and Meteorological Geographical Features (annex IV, section 13.2.1)


Corrigendum:





TC facilitator evaluation:
See issue reported under section “2.2.4 Code list GRIB_CodeTable4_2Value” of this document

The codelist GRIB_CodeTable4_2Value should probably be cut together with the ObservableProperties model; the other missing codelists should be sorted.


Kathi Schleidt: Wider Issue, many well defined and non-extendible codelists never made it to the IR


TC link(s):

2.2.8AM: Agglomerations (Directive 91/271/EEC)


Country /Issue number:

ES / 1


Affected article / annex:

Annex IV. 11.3.1



Theme(s): Area Management

Subject: Agglomerations (Directive 91/271/EEC)

Observations / problem description:

The concept of Agglomeration for the UWWTD is not considered in the INSPIRE model and consequently is lacking in the IR.




Proposed legislative change(s):
(including precise reference, current text and proposed amendment):

It can be included in Annex III. 11.3.1. Zone Type Code (ZoneTypeCode) as a new type of zone



Value

Name

Definition

aglomerattionUWWTD

Aglomeration for the UWWTD

an area where the population and/or economic activities are sufficiently concentrated for urban waste water to be collected and conducted to an urban waste water treatment plant or to a final discharge point



Rationale for change(s):

The concept is needed for reporting purposes

The definition of ‘agglomeration’ is given in Article 2(4) of the Directive 91/271/EEC: 'Agglomeration’ means: an area where the population and/or economic activities are sufficiently concentrated for urban waste water to be collected and conducted to an urban waste water treatment plant or to a final discharge point”


Expected impacts (including benefits):




TC facilitator evaluation:

No need to change IR. The Zone Type Code code list is ‘extensible with values at any level’, therefore they could add the desired values in their own national register according to the rules defined in the Annex C “Using extended code lists when sharing INSPIRE data” to the“ Best Practices for registers and registries & Technical Guidelines for the INSPIRE register federation”.



TC link(s):

2.2.9AM: Areas related to 91/271/EEC are missing


Country /Issue number:

ES / 2


Affected article / annex:

Annex IV. 11.3.1 and 11.3.2



Theme(s): Area Management

Subject: Areas related to 91/271/EEC are missing.

  • CAofSA catchment area of sensitive area

  • LSA less sensitive areas

  • NA normal areas

Observations / problem description:

The concept of ‘catchment area of sensitive area’ for the UWWTD is not considered in the INSPIRE model and consequently is lacking in the IR.

Other concepts lacking are:


Proposed legislative change(s):
(including precise reference, current text and proposed amendment):

They can be included in Annex III. 11.3.1. Zone Type Code (ZoneTypeCode) as new types of zones, but it would be more appropriate to delete from the Code list Zone Type Code the value ‘sensitiveAreas’ and substitute it by ‘receivingAreasUWWTD’

11.3.2. Specialised Zone Type Code (SpecialisedZoneTypeCode)

Value

Name

Definition

sensitiveArea

sensitive area

Water bodies identified as sensitive areas, as defined in Annex II to Directive 91/271/EEC ( 4 ).

receivingAreasUWWTD







Subsequently a change is needed in Annex III. 11.3.2. Specialised Zone Type Code (SpecialisedZoneTypeCode) where a code list stablishing values considered under EU legislation reporting obligations should be explicitly listed.

11.3.2. Specialised Zone Type Code (SpecialisedZoneTypeCode)

Additional classification value that defines the specialised type of zone.

The allowed values for this code list comprise the values specified in the table below and additional values at any level defined by data providers.



Value

Name

Definition

sensitiveAreaRW

Sensitive areas – rivers


Part of a river identified as sensitive areas, as defined in Annex II to Directive 91/271/EEC.

sensitiveAreaCL

Sensitive areas - coastline


Part of coastline identified as sensitive areas, as defined in Annex II to Directive 91/271/EEC.

sensitiveAreaLW

Sensitive areas – lakes,

Part of a lake identified as sensitive areas, as defined in Annex II to Directive 91/271/EEC.

sensitiveAreaCW

Sensitive areas– coastal

Part of a costal water identified as sensitive areas, as defined in Annex II to Directive 91/271/EEC.

sensitiveAreaTW

Sensitive areas – transitional waters

Part of a transitional water identified as sensitive areas, as defined in Annex II to Directive 91/271/EEC.

sensitiveAreaCatchment

Catchments of sensitive areas

Part of a river identified as sensitive areas, as defined in Annex II to Directive 91/271/EEC.

lessSensitiveArea

Less sensitive areas






Rationale for change(s):
(including concrete implementation evidence)

Those concepts are needed for reporting purposes under Directive 91/271/EEC.

For definitions see: Terms and Definitions of the Urban Waste Water Treatment Directive 91/271/EEC


Expected impacts (including benefits):




TC facilitator evaluation:

No need to change IR. Both the Zone Type Code (extensible at any level) and the Specialised Zone Type Code (empty codelist) are extensible, therefore they could add the desired values in their own national register according to the rules defined in the Annex C “Using extended code lists when sharing INSPIRE data” to the“ Best Practices for registers and registries & Technical Guidelines for the INSPIRE register federation”. Note:

they suggest ""it would be more appropriate to delete from the Code list Zone Type Code the value ‘sensitiveAreas’ and substitute it "", but this is in disagreement with the rules for codelist governance ""The maintenance will follow the procedures defined in ISO 19135. This means that the only allowed changes to a code list are the addition, deprecation or supersession of values, i.e. no value will ever be deleted, but only receive different statuses (valid, deprecated, superseded). "" Section 5.2.4.4 common to all DS.


TC link(s):

2.2.10Water Framework Directive WFD (2000/60/UE) Water bodies. waterBodyForWFD


Country /Issue number:

ES / 3


Affected article / annex:

Annex IV. 11.3.2



Theme(s): Area Management

Subject: Water Framework Directive WFD (2000/60/UE) Water bodies. waterBodyForWFD

Observations / problem description:

The WFD reporting obligations include certain different types of water bodies which are not considered under INSPIRE IR



Proposed legislative change(s):
(including precise reference, current text and proposed amendment):

The harmonization could benefit if they are included in Annex III. 11.3.2. 11.3.2. Specialised Zone Type Code (SpecialisedZoneTypeCode) as a new SpecialisedZoneType of the zoneType ‘waterBodyForWFD’


11.3.2. Specialised Zone Type Code (SpecialisedZoneTypeCode)

Additional classification value that defines the specialised type of zone.

The allowed values for this code list comprise the values specified in the table below and additional values at any level defined by data providers.

Value

Name

Definition

riverWaterBody


River water body




lakeWaterBody


Lake water body




transitionalWaterBody


Transitional water body




coastalWaterBody


Coastal water body




groundWaterBody

Ground water body







Rationale for change(s):
(including concrete implementation evidence)

The concept is needed for reporting purposes under WFD




Expected impacts (including benefits):




TC facilitator evaluation:

No need to change IR. The Specialised Zone Type Code is an empty codelist, therefore they could add the desired values in their own national register according to the rules defined in the Annex C “Using extended code lists when sharing INSPIRE data” to the“ Best Practices for registers and registries & Technical Guidelines for the INSPIRE register federation".



TC link(s):

2.2.11US: Discharge Points for treated waste water need to be added


Country /Issue number:

ES / 4


Affected article / annex:

Annex IV. 6 (5.2.1 and 7.2.1)



Theme(s): Utility and Government Services

Subject: Discharge Points for treated waste water need to be added.

This is particularly important in the case of discharges considered under UWWTD 91/271/EEC.




Observations / problem description:

Incongruities between what is regulated for water network (clean water) and sewer network (used network) need to be solved.

In the case of appurtenances in the Water network, Annex IV.6.7.2.1. Water Appurtenance Type (WaterAppurtenanceTypeValue) have in the code list establishing its classification, a discharge point

Value

Name

Definition

waterDischargePoint


water discharge point


Water discharge point

It is possible for a water network to have a discharge point for security reasons (overflows, maintenance, breakdown of a pump…), but it is not the most relevant appurtenance.

It is also considered an appurtenance a treatmentPlant which should be a type of Environmental management facility. It should be changed to treatmentDevice

In the case of appurtenances in the Sewer network, Annex IV.6.5.2.1. Sewer Appurtenance Type (SewerAppurtenanceTypeValue) the is no discharge point for treated waste water.have in the code list establishing its classification, a discharge point.


Proposed legislative change(s):
(including precise reference, current text and proposed amendment):

Waste water discharge points need to be added.

They can be added as an appurtenance in Annex IV.6.5.2.1. Sewer Appurtenance Type, but probably they have enough entity to be considered as a specific type in Annex IV.6 and an specific layer.


Rationale for change(s):
(including concrete implementation evidence)

This discharge point is needed for reporting purposes under Directive 91/271/EEC, and also for management purposes in waste water discharges not covered under the Urban Waste Water Treatment Directive 91/271/EEC



Expected impacts (including benefits):




TC facilitator evaluation:


TC link(s):

2.2.12US: Consider adding a new code list to the EnvironmentalManagementFacility


Country /Issue number:

ES / 5


Affected article / annex:

Annex III. 6



Theme(s): Utility and Government Services

Subject: Consider adding a new code list to the EnvironmentalManagementFacility.



Observations / problem description:

The options considered in the code list of Annex 6.6.8.2.1. Environmental Facility Classification (EnvironmentalManagementFacilityTypeValue) which only include as values ‘installation’ and ‘site’ needs further development to be useful to interoperate.



Proposed legislative change(s):
(including precise reference, current text and proposed amendment):

Developing a new code list under Annex 6.6.8.2.1

6.8.2.1. Environmental Facility Classification (EnvironmentalManagementFacilityTypeValue)

Classification of environmental facilities, e.g. as sites and installations.

The allowed values for this code list comprise the values specified in the table below and narrower values defined by data providers

Value

Name

Definition

drinkingWaterTreatmentPlant







wasteWaterTreatmentPlant







reclaimedWaterPlant







desalinizationPlant







pumpingStation







wasteDisposalSites







vehicleDismantlingFacilities







brownfields















To be further developed


Rationale for change(s):
(including concrete implementation evidence)



Expected impacts (including benefits):



TC facilitator evaluation:


TC link(s):

2.2.13AM: Values for the code lists ZoneTypeCode and EnvironmentalDomain


Country /Issue number:

SPAIN/2



Affected article / annex:

11.3.1/11.3.3



Theme(s): Area Management/Restriction/Regulation Zones and Reporting Units

Subject: Values for the code lists ZoneTypeCode and EnvironmentalDomain

Observations / problem description:

Problems modeling the areas of responsibility of various governmental services such as hospitals or schools.




Proposed legislative change(s):
(including precise reference, current text and proposed amendment):

Extend the codelists:



  • ZoneTypeCode: at least with the value “other” for non-environmental purposes. Desirable to extend with other values such as “health management”, “educational management”, etc.

  • Environmental Domain: at least with the value “other” for non-environmental purposes. Desirable to extend with other values such as “health management”, “educational management”, etc.




Rationale for change(s):
(including concrete implementation evidence)

In Spain, the areas of responsibility of various governmental services are not administrative units or named places but specific health or school zoning. For example: health centre, primary school, fire station must be associated to health, scholar, emergencies areas of responsibility.



Expected impacts (including benefits):





TC facilitator evaluation:

NOT OK, for two main reasons: 1. In the Data Specification on AM - Section 2.2.2 Scope related to the Area Management, Restriction and Regulation Zones - we read that the ”Area Management, Restriction and Regulation Zones are zones established in accordance with specific legislative requirements to deliver specific environmental objectives related to any environmental domain, for example, air, water, soil, biota (plants and animals), natural resources, land and land use.” Therefore, in my understanding, “modelling the areas of responsibility of various governmental services such as hospitals or schools” in the scope of AM data theme, means to classify them according to the related environmental purpose - e.g. health (http://INSPIRE.ec.europa.eu/codelist/EnvironmentalDomain/healthProtection), sustainable development (http://INSPIRE.ec.europa.eu/codelist/EnvironmentalDomain/sustainableDevelopment), etc. Adding values to the (not extensible) Environmental Domain codelist for non-environmental purposes is not appropriate. 2. The Zone Type Code code list is ‘extensible with values at any level’, therefore they could add the desired values in their own national register according to the rules defined in the Annex C “Using extended code lists when sharing INSPIRE data” to the“ Best Practices for registers and registries & Technical Guidelines for the INSPIRE register federation”. No need, in my view, to change IR

Kathi Schleidt: Note: it could make sense to align (or combine) this codelist with http://inspire.ec.europa.eu/codeList/MediaValue


TC link(s):

Thematic Cluster page on code list extension: https://themes.jrc.ec.europa.eu/pages/view/162571/how-to-extend-INSPIRE-code-lists

TC discussions on code list extension: https://themes.jrc.ec.europa.eu/discussion/view/119293/extending-of-code-lists https://themes.jrc.ec.europa.eu/discussion/view/137515/cultural-heritage-protected-sites




Yüklə 0,54 Mb.

Dostları ilə paylaş:
1   2   3   4   5   6   7   8




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©muhaz.org 2024
rəhbərliyinə müraciət

gir | qeydiyyatdan keç
    Ana səhifə


yükləyin