Separate SHACL-shape for 'Georeference'

[rcrswld]

The PLC-specific SHACL-shape for domain-specific metadata of scenarios includes attributes regarding georeferences. As aligned in AP 3.3 / data-provider-meeting, we would like to use those attributes also for other data categories in a similar way. Therefore we need a separate folder, ontology and SHACL-shape for georeference.

I will delete the georeference-related parts from the scenario-SHACL and copy it hereby. Please take it as a starting point for the new shape.

[3Dbastian]

Created the Georefernce shape in the branch Ontology_Georeference

[3Dbastian]

What is not completley clear to me: you still write all attributes of georeference into the shacl, only referring to this other class. Assuming we have georeference in shacl of HDMap, SurfaceModel, Scenario. In all shacls we still have to add all the attributes every time. Or did you do it that way, only until the Georeference Shape is created? So the actual question is: Is there another linking mechanism, so we can just say for Scenario, use everything from Georeference?

[3Dbastian]

TOPIC EPSG Code: Here https://github.com/GAIA-X4PLC-AAD/ontology-management-base/pull/6#discussion_r1605135200 @rcrswld @robertschubert ask for valid values.

Valid values are 4 or 5 digit integers ranging from 1024 and 32767 with officially defined georeferece meanings. Custom 5 digit codes larger than that numbers are allowed.

Additonally there should be the option to give no data might be in just a catesian coordinate system with no "earth relation". To allow only valid EPSG codes, i would suggest to either include another attribute like islocal, isearthrelated.

So no you migth say, we can leave the georeference completly (e.g. for a completly artificial dataset, e.g. the CARLA town). In my opinion there is also the case, that we can define a location where the data comes from like Autobahn A8, and have a map of this, but we destroy completley all georeference information for the map coordinates with respect to simulator requirements.

[3Dbastian]

@rcrswld @heuerfin I have only a look on the static site, is there any demand for geolocation from the dynamic (scenario) site.

[3Dbastian]

@MircoNierenz You asked for replacing EPSG code with WKT. In my opinion EPSG is the most convinient and concise way to represent the coordinate systems. Perhaps you have a look on epsg.io (eg. for UTM in Germany https://epsg.io/25832). There you can find all version of projections strings for the same coordinate system.

We might define the SHACL with giving the type of projection string in one attribute and then the corresponding string in the actual defintion of the coordinate system. But in this case a potential marketplace (@jtdemer demer) the user would either have to know about all the projection strings, or the marketplace would have to unify them again, to provide one type for filtering.

My opinion is just to use EPSG, but I would also go with another solution, if requested by other data provider / consumer.

[3Dbastian]

What is not completley clear to me: you still write all attributes of georeference into the shacl, only referring to this other class. Assuming we have georeference in shacl of HDMap, SurfaceModel, Scenario. In all shacls we still have to add all the attributes every time. Or did you do it that way, only until the Georeference Shape is created? So the actual question is: Is there another linking mechanism, so we can just say for Scenario, use everything from Georeference?

What is not completley clear to me: you still write all attributes of georeference into the shacl, only referring to this other class. Assuming we have georeference in shacl of HDMap, SurfaceModel, Scenario. In all shacls we still have to add all the attributes every time. Or did you do it that way, only until the Georeference Shape is created? So the actual question is: Is there another linking mechanism, so we can just say for Scenario, use everything from Georeference?

is answered here: https://github.com/GAIA-X4PLC-AAD/ontology-management-base/pull/6#issuecomment-2129382676

[heuerfin]

@rcrswld @heuerfin I have only a look on the static site, is there any demand for geolocation from the dynamic (scenario) site.

Hm... I'm not quiet sure. Somehow it could be interesting for a user to have some knowlegde about the synthetic drivable area in a scenario. OSC has positions like World, Geo, Road/Lnae positions. However, these could be mapped to the ODR. So I think there is no further need for any custom positions (even though there are relative positions and but I think these could be also mapped). However, is it currently clear how we deal with synthetic maps? Do we assign an EPSG code or is there any "spare/reserved" coder available for something syntheically not belonging directly to "earth"?

[3Dbastian]

in our discussion we came up to make to optional fields:

• EPSG code if possible
• projection information -> @ Fin: I think a synthetic map has usually no projection, but this field could be used with the keyword "local" to indicate a arbitrary system

local than means that there is no scale within this map, all projected map showing something from the real world have usally a distance scaling within (UTM, GK)

[heuerfin]

That sounds good from my point of view. @MircoNierenz we also discussed the XOR relationship between those two fields. I think with specifying local would be also fine.

However, regarding the data types it will become a bit difficult, right?

• epsg code: data type: string - epsg code - "EPSG:12345"
• projection information: data type: string - "description" or WKT string? Or is this meant for human readable string?

[3Dbastian]

EPSG:

• data type of epsg code could also be just a integer, its always a 4 or 5 digit number, and we do not use the EPSG:, since it's defined in the description Projection:
• if the keyword is projection, than actually we could write "local", "mercator", "geographic" -> but only mercator is actually a projection, perhaps we can write coordinate system, then we could use UTM32, local, geographic, GK. This would be a string with no real definition, like proj4

@heuerfin @MircoNierenz: let's discuss this at the meeting next week