INSPIRE Community Forum

Liked content

  • By Julián DELGADO

    Dear all

    I countinued working with coverages encoding, where the range type data (=pixel values) is provided using a WCS service instead attached images files like ISO or INSPIRE propose. Below I put the foundamental XML labels, in order to share it and obtain advices from the rest of the community. Would it be well done? any idea on it? As you see I used a getCoverage request.

     

       <gml:rangeSet>
        <gml:File>
         <gml:rangeParameters xlink:href="http://www.ign.es/wcs/mdt?service=WCS&request=GetCoverage&version=1.0.0&coverage=mdt:Elevacion25830_25&CRS=EPSG:25830&bbox=484387.5,4778987.5,512212.5,4798212.5&WIDTH=1113&HEIGHT=769&FORMAT=geotiff" xlink:role="http://www.opengis.net/spec/WCS_coverageencoding_geotiff/1.0/" xlink:arcrole="fileReference"/>
         <gml:fileReference>geoserver-GetCoverage.tiff</gml:fileReference>
         <gml:fileStructure/>
         <gml:mimeType>image/tiff</gml:mimeType>
         <!-- This encoding way is a proposal, required to be shared and validated with other encoding examples for coverages using WCS. Native CRS is used for data providing -->
         <!-- WCS provides the coverage in the native reference systems (EPSG:25830 and national altimetric system) -->
        </gml:File>

    Best regards

  • By Julián DELGADO

    Dear Emmanuel, Jordi

    During last days I spent time working with GMLs for elevations. As Emmanuel pointed I didn't find a online reference for the elevation concept. I used a fictitious one to continue working, but should be updated. Proposed links from dbpedia and nasa seems good because they are refered to 'elevation' or 'altitude' concept, however links from opengis and csriso are related with the definition of the reference system, different things from my point of view.

    Althoght the most interesting fact that I propose with my GML example is how I encoded the range type data (=pixel values). I proved to do it using a WCS service instead attached images files like ISO or INSPIRE propose. Below I put the foundamental XML labels, in ordet to share it and obtaing advices from the rest of the community. Would it be well done? any idea on it? As you see I used a getCoverage request.

     

       <gml:rangeSet>
        <gml:File>
         <gml:rangeParameters xlink:href="http://www.ign.es/wcs/mdt?service=WCS&request=GetCoverage&version=1.0.0&coverage=mdt:Elevacion25830_25&CRS=EPSG:25830&bbox=484387.5,4778987.5,512212.5,4798212.5&WIDTH=1113&HEIGHT=769&FORMAT=geotiff" xlink:role="http://www.opengis.net/spec/WCS_coverageencoding_geotiff/1.0/" xlink:arcrole="fileReference"/>
         <gml:fileReference>geoserver-GetCoverage.tiff</gml:fileReference>
         <gml:fileStructure/>
         <gml:mimeType>image/tiff</gml:mimeType>
         <!-- This encoding way is a proposal, required to be shared and validated with other encoding examples for coverages using WCS. Native CRS is used for data providing -->
         <!-- WCS provides the coverage in the native reference systems (EPSG:25830 and national altimetric system) -->
        </gml:File>

    Example of EL GML encoding

     My best regards

  • By Marc ROESBEKE

    Jordi,

    Yes, I agree that bathymetric elevation data shall be provided either as gridded or vector data.

    Tidal waters will use LAT as height reference. This is in line with the recommendation from IHO. IHO has not defined the procedure of how to realize LAT. The member states are responsible to define LAT. It is also upto the member states where the definition of tidal waters ends and where non-tidal waters begins.

    EVRS does not surround a non-tidal sea area. Closest is the link at coastal tidal stations where MSL, LAT and EVRS values are available. If MSL-EVRS relation is available, then the depths can be reported in EVRS and in metadata the relation between MSL and EVRS should be given. Displaying in EVRS allows a smooth transition to adjacent rivers.

    Displaying depth values in rivers can be done using EVRS. The offset between a common riverwaterlevel in EVRS height can be used as reference. Using the same philosophy of LAT, this common level should have a such a value that only 5% of all times the actual water level is less. (setting this standard is for example a task of the North Sea Tidal Working Group).

    If someone wants to use land reference (such as EVRS) to describe sea-floor data, it is possible to consider these data as "height" with negative values. It means that, as far as safety of navigation is not concerned, the bottom of the sea can be described exactly like any topographic surface on land.

    Marc

  • By Jan ŘEZNÍČEK

    Local or national CRSs registers are not used in the Czech Republic, established practice is to use EPSG identificators of CRS.

    Situation in the description of transformations within the current registers (EPSG or CRSeu) is really somewhat ambiguous. Transformation procedures described in these registers are mostly only approximate (there are generally described only parameters of Helmert transformation) with the accuracy of some meters.

    It is little complicated or eventually impossible to describe precise transformations within these registers. For example precise transformation between Czech national CRS (EPSG:2065 S-JTSK (Ferro) / Krovak) and ETRS89, includes not only Helmert transformation and equations of projection, but also transformation grid with the range of 2x2 kilometres. And the question is: How to describe transformation grid within the CRSs registers?

    If the current CRSeu register will be actualized or the new register will be developed (possibly with the functionality of international transformation service), it would be also useful to implement possibility of upload transformation grid within this register (directly or as a weblink). Other posibility is to publish web links to the national transformation services within this register.

  • By Markus SEIFERT

    How to implement Data Specification on Coordinate Reference Systems?

    According to the Interoperability Implementing rules (IR) (Annex II, sec. 1.5. in the consolidated version), coordinate reference system (CRS) parameters and identifiers shall be managed in one or several common registers for CRS. Only identifiers contained in a common register shall be used for referring to the CRS listed in the IR (Annex II, sec. 1).

    Requirement 1 of the Technical Guidelines (TG) for CRS stipulates the use of http URIs provided by the Open Geospatial Consortium as coordinate reference system identifiers (http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_RS_v3.2.pdf, p 15). These are based on and redirect to the definition in the EPSG Geodetic Parameter Registry.

    In the German Surveying Authorities’ view, CRS parameters and identifiers should be provided and maintained by an authorized, official institution. Additionally, a need to register other (local) CRS which are not included in the EPSG Registry, is seen. Therefore, the German Surveying Authorities decided to set up an own web-based CRS registry as part of the German SDI Registry (GDI-DE Registry). This approach is based on the ISO/TC 211 Registry for geodetic codes and parameters which is currently under development. The German SDI will use this open source software and implement some additional specific requirements.

    The Implementation will be based on

    − ISO 19111 Spatial referencing by coordinates

    − ISO 19127 Geodetic codes and parameter

    − ISO 19135 Procedures for item registration.

    The registry also contains transformation parameters in order to establish transformation services (WPS) and will replace the current implementation of the Coordinate Reference Systems of Europe (CRS-EU). The question is, whether there are any similar approaches in other countries to set up an European federation of CRS registries?

     

    When there are several activities in the field of CRS registers, the need for coordination (e.g. at European level) is seen in order to avoid duplication and interoperability issues. Thoughts should also be given to the usability in GIS-clients, as registry implementations which are independent of the EPSG Registry would lead to new CRS-identifiers.

     

    However, according to its terms of reference, the scope of the work in MIWP-6 Registries and registers (https://ies-svn.jrc.ec.europa.eu/projects/inspire-registry/wiki) is limited to the registers currently included in the INSPIRE Registry (i.e. doesn’t include the CRS topic).

     

  • By JAVIER GONZALEZ MATESANZ

    Totally agree Jordi. Anyway, a clear rules to transform national data to EVRF2000 should be written somewhere.

    Contour regeneration would not be a problem as far as can be obtained from DTM but the collateral efects are still not known. In the Spanish case, an offset of 49cm must be applied to have EVRS ellevations.

    Then, yes. The richness of true 3D vector data of national agencies is lost in order to be consistent with elevation models and that models could have two different transformations: a) the rigorous tilted plane as published in crs.eu or b) a simple elevation offset in case the differences along the country were neglectables

  • By Kenneth BRAGG

    Hi Julián

    Thanks for posting your experiences. I work for Safe Software the makers of FME and I'd like to follow-up on your point #3: "...they couldn’t recognize all <labels/> from the INSPIRE XSD needed for GML COV". Can you give me a bit more information on this issue. I would like to see if there is anything we can do in FME to solve this problem but I don't think I understand the issue.

    Thanks

    Ken Bragg

  • Example data in accordance with OI application schema (for Copernicus guidelines)

    Started by Michael LUTZ in the group Elevation, Ortho & Grids Replies (4) Last reply by Jordi ESCRIU
    Dear OI experts, we have recently been asked for feedback on a draft technical note on "INSPIRE Metadata Tailoring Guidelines for Copernicus Contributing Missions (CCMs)" currently being developed by ESA. During the discussions, the...
  • ETRS89-TMzn and raster data for OI and EL

    Started by Marcin GRUDZIEŃ in the group Elevation, Ortho & Grids Replies (9) Last reply by Jordi ESCRIU
    I have some doubts regarding  use of valid INSPIRE coordinate reference system (CRS) especially for providing raster data for orthoimagery (OI) and elevation (EL) themes. According to Regulation No 1089/2010 of 23 November 2010 implementing...
  • By Lars ENGBERG

    Hello Marcin,

    I was member of TWG-RS but since it was closed, I have not been involved in Inspire-work so take my comments on 1.3.2 with that reservation.

    1.3.2.  Two-dimensional Coordinate Reference Systems

    • Two-dimensional geodetic coordinates (latitude and longitude) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid.
    • Plane coordinates using the ETRS89 Lambert Azimuthal Equal Area coordinate reference system.
    • Plane coordinates using the ETRS89 Lambert Conformal Conic coordinate reference system.
    • Plane coordinates using the ETRS89 Transverse Mercator coordinate reference system.

    From my point of view it is totally clear, the meaning of the line in 1.3.2 above is: ETRS89-TMzn, which is equivalent to a UTM-zone, a reference frame that is a realization of ETRS89 and the GRS80 ellipsoid. As I remember, we intentionally omitted reference to EPSG codes because this was not an official registry.

    So, Marcin you have to convert the co-ordinates from PUWG 1992 to ETRS89-TM33, TM34 or TM35 depending on where in Poland you operate.

    In Sweden, we have our own system SWEREF 99 TM that is equivalent to ETRS89-TM33 for almost all Sweden (within UTM-zone 33) but in the eastern part we have to convert to ETRS89-TM34 to fulfill the Inspire rules.

    I don't know why TMzn is omitted in 1.3.2. Much better wording in 1.3.2 had been something like this:

    1.3.2.  Two-dimensional Coordinate Reference Systems

    • Two-dimensional geodetic coordinates (latitude and longitude) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid.
    • Plane coordinates using the ETRS89-LAEA coordinate reference system.
    • Plane coordinates using the ETRS89-LCC coordinate reference system.
    • Plane coordinates using the ETRS89-TMzn coordinate reference system.

    Using the identifiers implies all parameter values for the projections and no uncertainty appears.