INSPIRE Thematic Clusters

Question about encoding option in the elevation theme

463 Views

Hi,

I could transform  small bathymetry dataset into an Inspire compliant gml file (xml validated by Hale) but I realize that gml is not convenient for large files as I would have to split the original file into many smaller files. I only worked on mandatory attributes.

So I think the options offered in point 9.3 of the DS (2013-12-10) is more convenient, that is to encode all the coverage components into a gml file except the range set (depth) which would be encoded into a second file.

But I would like to also encode the domainset (x,y coordinates of the gridpoints) into this second file  to reduce the overall size.

So my question is : as gml format is not legally binding, what prevents me from encoding the domainset into this second file?

Thank you

P Jamagne

Replies

    • Public

    By Jordi ESCRIU

    Dear Pierre,

    Many thanks for publishing your question.

    In my view you are right - The encoding rules included in the technical guidelines are proposed as default encodings, but you shall follow them if you use such encodings (this is the meaning of TG Requirements). You have different options available, but all of them based completely or partially on GML.

    If you follow other encoding rules you shall ensure compliance with the implementing rule requirement in section 9.4:

    1. Every encoding rule used to encode spatial data shall conform to EN ISO 19118. In particular, it shall specify schema conversion rules for all spatial object types and all attributes and association roles and the output data structure used.
    2. Every encoding rule used to encode spatial data shall be made available.

    I understand that your main problem seems to be the size of the resulting GML files. Other data providers are also dealing with the same problem. A common approach is to split the full elevation coverage into smaller pieces or tiles. 

    Are you also using tiles in your encoding?

    Just to mention here that the use of the default encodings should be followed as possible in order to increase harmonization.  

    In case it is useful for you - Please have a look at the following discussion thread and related links, about issues encoding coverage data:

    https://themes.jrc.ec.europa.eu/discussion/view/49909/how-to-encode-coverages-gmlcov-example-files-and-improvement-of-tg-related-explanatory-sections

    Jordi

    • Public

    By Pierre JAMAGNE

    Hi,

    Thank you for the reply

    1.To Andres solution : It is not clear to me if your index file contains the geometry of each enclosing rectangle or only a code for each of them.

    2.To Jordi’is reply:

    The survey area is made of three large polygons in the North sea  as you can see in the following picture. The gridpoints are 1 m from each other in wgs84 UTM31N crs. I have just received a piece of one of them and I do not know what the original building blocks look like (my data providers are now on leave) . It would be possible to cut them into 1 km squares but we would have close to 500 hundred smaller files, which looks huge to me. I would prefer to have fewer files to handle.

    image

    3. Do you work this out with FT Eleavationgridcoverage and Elevationgridcoverageaggregation? If you have used Hale, would it be possible to have a look on your mapping?

    Thank you

    P Jamagne

     

    • Public

    By Peter PARSLOW

    Pierre,

    perhaps what you are looking for is satisfied by encoding the gml:RectifiedGrid in the way that we do for OS Terrain, which is to use the gml:File option to encode the 'range set'. Of course it encodes the domain in a way to, in that a GeoTIFF does geolocate each of the values. Assuming your domain is a regular grid, the encoding is quite compact (see the example in the TG), simply specifying the 'lower left' corner & the offset vector for each point. Our .gml files are about 3Kb, regardless of tile size.

    There are a few things overdue for correction in OS Terrain, to bring it in line with the published INSPIRE spec (we created & published the data against the final draft spec) - in particular, our external files are ASCII grid, which was an option right up to the last release candidate.

    Peter

    • Public

    By Andres OSTMAN

    The index file is in my case a shape file with one enclosing rectangle for each TIFF file. This means that the geometry is included in the shape file, imported HALE. The attributes must then also include all INSPIRE elements that are unique for each TIFF file, like the URL of the TIFF file and the coordinates of the origin.

    I have so far only used ElevationGridCoverage, no aggregations.

    Kind regards

    Anders

     

    • Public

    By Pierre JAMAGNE

    Reply to Peter,

    I understand that in the solution proposed by Peter, if  the territory is covered by  100 tiles and so many geotiff, you will have 100 gml file and there is not a polygon file containing the one hundred enclosing rectangles.

    Is my understanding correct?

    In your ETL tool  (Hale for instance), what do you use as input file?

    How do you generate the domain extent attribute?

    Reply to  Andres

    I understand that in the  solution proposed by Andres, the input file in the  ETL tool  is the polygon vector file with so many rectangles as there are tiles to cover the territory. For each rectangle, in the input file you have as attribute the url adress to the raster file, the coordinates of the origin, and other mandatory attributes.

    With your solution, your need only one gml file

    Is my understanding correct?

    Thank you

    P Jamagne

     

     

    • Public

    By Peter PARSLOW

    I believe you're correct - OS Terrain 50 (with a 50m grid spacing) consists of nearly 3000 sets of files, with each set containing five files (the GML & ASCII grid, plus a metadata file about flying dates etc, plus a couple of files beyond INSPIRE to make it easy to load the ASCII into Arc); I hate to think how may our 5m grid products contains!

    We don't use ETL to produce it, in a conventional sense. We create the files from a 'seamless' content store (with our own internal data model), using a mix of python & FME if my memory serves correctly. It's all part of an integrate & complex multi-product flowline.

    As I mentioned, OS Terrain doesn't properly conform with the INSPIRE specs. One aspect is that we don't explicitly include ElevationGridCoverage.domainExtent. The information is available in the gml:boundedBy attribute of the feature collection (tile) - it's simply the extent of the tile. This is correct because we fill each tile - perhaps that's an advantage of not having any tiles that overlap with another Member State!

    Peter

    • Public

    By Andres OSTMAN

    Hi Pierre,

    You have understood me correctly. Just two things to add

    1. The attributes in the shape file only have to be the elements that varies. If there are constant values, for instance the orientation and length of the offset vectors, you can assign these values in Hale.

    2. According to INSPIRE, the origin of the grid should be the upper left corner, not lower left as I have seen in this thread.

    Kind regards

    Anders

     

    • Public

    By Pierre JAMAGNE

    Hi,

    I will start on with the solution proposed by Andres as it seems to me simpler as I need to manage only one gml file which will contain all my tiles.

    My original grid is a grid  that has  been designed in wgs84UTM31N, with each point 1 meter apart from each other and . I have transformed it into ETRS89 UTM31N which to me doesn't make any difference. 

     

    First question

    Having made a retype (using  HALE) between My source file (polygon shapefile with tiles) and the schema Elevationgridcoverage, I guess I have to go the following way :

    domainset>domainset>choice>abstractgeometry>rectifiedgrid >choice> and I am faced with attributes axislabels and axisname :

    How do I have to fill axislabels and axisname attributes?

    Second question : Is the following correct?

    • For dimension, I have assigned 2;

    • for Id I have used the generate unique Id function

    • For low high under gridenvelopes,I will encode the coordinates of lower left corner and of the upper right corner

    • For offset vector : I have assigned 1.0 1.0 as my grid points are 1 m apart from each other along x and y axis

    and under offsetvector I assigned in the following way :

    For the originpoint of the grid, I did record their coordinates under  the property Pos.

    Thank you

    Pierre Jamagne

    • Public

    By Andres OSTMAN

    Hi Pierre,

    Your questions are quite similar to questions I filed on this forum about a year ago. I have still not really received good answers to them, so what I write here are my personal opinions, not sanctioned by the INSPIRE team. In addition, there are inconsistencies within the data specifications itself and also inconsistency with the schema. Since I need to have a working solution, I have put the schema in priority, in cases where I have detected such conflicts.

    Now to your questons

    1. Add an additional domainSet.rectifiedGridDomain.choice.AbstractGeometry.RectifiedGrid.choice.axisName by right-clicking it and select Add instant context. Assign ’x’ and ’y’ to the two names. I don't use label at all.

    2. Dimension = 2 is OK, also sequential or unique ID (I use sequential, but it really doesn't matter as I see it).

    3. Set limits.GridEnvelope.high to ‘5000, 5000’ and low to ‘0,0’ (if that is the size of the grid). So they are the internal co-ordinates, as specified by the data specification.

    4. The offset vector consists of an offset direction and grid spacing. We need two offset vectors (one for x and one for y), so start by adding a new instance in the target file (right-click and Add instant context). Then specify ’90 1’ for the first offset vector (direction 90 degrees, 1 m spacing) and ’x’ for its name. Do the similar way for the y offset vector. I don't specifically assign the srsname and uom label of the offset vectors, but of course that is clarifying.

    5. Since I have the origin of the grid in two separate attributes in the shape file, I specify the origin through the Hale function Ordinates(xmin, ymax) -> origin.Point

    Kind regards

    Anders

     

     

    • Public

    By Pierre JAMAGNE

    Hi Anders,

    Thank you very much for your reply,

    I have still some comments and questions

    1. axisname/axislabel :  

    I have choosen to use axislabels as the description of the property in Hale says “list of values” and I have filled it with simply assigning :  x y (x and y being separated by a space).

    Indeed on the net, others have  done :

    axisLabels="x y" (http://www.ogcnetwork.net/gml-point);

     axisLabels="Lat Long" time" (http://docs.geoserver.org/latest/en/user/extensions/wcs20eo/index.html)

    <gml:axisLabels>x y</gml:axisLabels>(http://csiss.gmu.edu/cesir/files/gmu_wcs_v2.pdf)

    2. The offset vector :

    I have assigned like what I have seen in the Inspire DS p.126:

    <gml:offsetVector>1 0</gml:offsetVector>

     <gml:offsetVector>0 1</gml:offsetVector

    But nowhere I have seen the angle. Why do you specify 90?

     

    3. About origin point and domainextent : I have as many of them as there are tiles s in my input file, thus four different originpoints and four  different domainextent polygons.

     Is that correct?

    Sincerely yours,

    P Jamagne 

Elevation, Orthoimagery, Reference Systems and Geographical Grids Cluster

Elevation, Orthoimagery, Reference Systems and Geographical Grids Cluster

INSPIRE Thematic Cluster Elevation, Orthoimagery, Reference systems, Geographical grids - Join this group to share your knowkledge, learn and collaborate in solving issues related to the Elevation, Orthoimagery, Reference systems and Geographical grids themes