fhooeaist/geofiles

Evaluation of file formats in the context of geo-referenced 3D geometries.

geofiles's Issues

GeoOBJ

Currently, we are using the o prefix for origin information in geoobj. Unfortunatley, this prefix is already in use in classic obj for object names (http://paulbourke.net/dataformats/obj/).

So we have to switch to another line prefix like or.

GeoVRMLWriter: Duplicate Coordiantes

The coordinate list that is created by the GeoVRML writer contains vertex duplicates. This should not be the case and has to be fixed.

GmlReader

Add a reader implementation for Gml. Add the information that this is connected to semantic loss.

GeoVrmlReader

Add a reader implementation for GeoVrml. Add the information that this is connected to semantic loss.

Writer: WriteToString support

Add a possibility for writing to a string instead of a file

Minimize() GeoObjectFile

Add a minimize() function to the GeoObjectFile class, which will combine all GeoObjects to one, as required for e.g. GeoOFF or GeoPLY

Rework transformer update extent

Instead of checking if input data had extent information, add a flag to the transform methods, which decides if extent information is updated. Also, it would be more performant to add this directly to the transformation process instead of re-iterating the vertices add the end.

This is especially important for the OriginTransformer, since the original extent information may be interesting also in origin-based representation.

GeoJsonReader

Add a reader implementation for GeoJson. Add the information that this is connected to semantic loss.

Extent Feature to README Table

Add another column to the feature comparison according to the geographical extent information (for cityjson, geoobj, geoply, ...)

CityJSON Origin support

Add origin support to CityJSON using the transformation object

GetTransformedExtent

Add a possibility for calculating the geographical extent of a GeoObjFile, considering the included transformation and origin information.

add quantization to CityJSON files

First, very interesting work, thanks for doing this!

I noticed that the CityJSON files are not created with the "transform" (https://www.cityjson.org/specs/1.0.3/#transform-object) and that would save ~10%. If you use cjio you can use the compress operator (and specify the number of digits to keep, default is 3).

By the way, CityJSON v1.1 will be released later this month, and with that version the "transform" will become mandatory.

glTF support

Add glTF support (https://github.com/KhronosGroup/glTF-Tutorials/blob/master/gltfTutorial/gltfTutorial_002_BasicGltfStructure.md)

Meta Information

Extend the proposed formats (GeoOBJ, GeoPLY, GeoOFF) by supporting additional meta information on object level in the form of a triple (typed key/value pair) consisting the following information:

• name: string
• type: string (optional default type string or float for numerics)
• value: type

Reader: ReadString support

Add support for parsing strings representing e.g. 'geoobj' file content.

CityGML support

Also if CityJSON and GML are already supported, extend the support to CityGML.

CityJsonReader

Add a reader implementation for CityJson. Add the information that this is connected to semantic loss.

Recreate Interactive Visualizations

Recreate: https://fhooeaist.github.io/geofiles/

Object based transformation support

Adapt the current implementation to support object based transformation instead of a single file based transformation.
This requires #17.

In case of GeoOBJ, transformation information should be associated to the current object.

GeoOFF and GeoPLY: Single object support

Adapt the GeoOFF and GeoPLY writer implementations to require single objects.

KmlReader

Add a reader implementation for Kml. Add the information that this is connected to semantic loss.

Differentiation between file and object meta information

In 2.0.0 we introduced meta information for objects.
Should be extended to also have file based meta information.

Default Meta Information

Define default meta information that can be used in the proposed file formats e.g.:

• Unit for transformations with default metres

CityJsonWriter GeographicalExtent

The GeoObjFile domain class may contain geographical extent information. Forward this information to CityJson if it is available.

Update Feature Comparison

Update the Feature Comparison based on the table of the associated paper.

OGC support

Add OGC support (https://github.com/opengeospatial/ogc-feat-geo-json)

GeoOBJ: Hierarchy Parameter

Currently, GeoOBJ can only represent a flat hierarchy. Add a hierarchy parameter that allows to navigate one level up or down, allowing to create a tree-like object structure.

CityJson v1.1 Reader

Transformation information was added to CityJsonWriter in Issue 28.
These changes also have to be introduced to the CityJsonReader.

how can some files be smaller than the baseline?

Just a question: I noticed that some files are smaller than the baseline OBJ (mostly CityJSON, geoobj, geoply) and I am puzzled. Is it because you took the OBJ file as is and it contains vertex normals and face normals?

Add Collada .dae support

Add support for collada .dae files.

See also:

• https://www.khronos.org/files/collada_spec_1_5.pdf
• https://stackoverflow.com/questions/40719661/collada-dae-file-structure-and-pycollada
• https://stackoverflow.com/questions/26519971/minimal-example-for-a-colored-cube-in-collada-displayed-in-google-earth

Dependency Dashboard

This issue provides visibility into Renovate updates and their statuses. Learn more

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency pyrsistent to v0.18.1
• Update dependency attrs to v21.4.0
• Update dependency certifi to v2021.10.8
• Update dependency cjio to v0.7.3
• Update dependency click to v8.1.3
• Update dependency pyproj to v3.3.1
• Update dependency certifi to v2022
• Update dependency jsonschema to v4
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

pip_requirements

requirements.txt

• pyproj ==3.1.0
• attrs ==21.2.0
• certifi ==2021.5.30
• cjio ==0.6.9
• click ==8.0.1
• colorama ==0.4.4
• jsonref ==0.2
• jsonschema ==3.2.0
• pyrsistent ==0.18.0
• six ==1.16.0

---

• Check this box to trigger a request for Renovate to run again on this repository

GeoOFF Header support

Extent the header line by the following pattern for transformation and origin support:
[t][r][s][o]GeoOFF

• GeoOFF -> CRS
• oGeoOFF -> CRS + Origin
• tGeoOFF -> CRS + translation information
• rGeoOFF -> CRS + rotation information
• sGeoOFF -> CRS + scalinginformation
• trsoGeoOFF -> CRS + Origin + translation + rotation +scaling

GeographicalExtent

The CityJson format supports the GeographicalExtent meta information, which allows filtering fast if a file is within a given region of interest or not. This feature could be also added to .geoobj and .geoply.

Proposed .geoobj and .geoply extension with the line prefix e followed by 6 values (first 3 min extent, remaining 3 max extent):

...
e 0 0 0 10 10 10
...

geoply
...
extent 0 0 0 10 10 10
...
end_header

Metadata Validator

Implement a mechanism to define a schema for GeoOFF, GeoPLY and GeoOBJ metadata.
This mechanism should allow defining the structure of required and optional meta information on file and/or object level.
A schema should consist of a key that references the meta-information key within the geometric file and with one or multiple values. Each value should correspond to the associated data type, and should also allow to define range constraints for numeric as well as string values.

The attributed grammar of such a metadataschema would somehow look like:

File = "File:\n" + Metadefinitions + "Object:\n" + Metadefinitions
Metadefinitions =  Metadefinition | Metadefinitions + Metadefinition
Metadefinition = Key Required Typedefinition '\n'
Key = string
Required = 'r' | 'o'
Typedefinition = TypeChain | TypeChain Multitype
TypeChain = Type | Type TypeChain | LimitedMultiType | LimitedMultiType TypeChain
LimitedMultiType = Integer '*' Type
Multitype = Type + '*'
Type = TupleType | NumberType | StringType | 'datetime' | 'bool'
TupleType = '(' TypeChain ')'
NumberType = 'int' | 'int[' IntRange ']' | 'float' | 'float[' FloatRange ']'
IntRange = integer [IntRange] | [integer]:intger [IntRange]
FloatRange = float [IntRange] | [float]:float [IntRange]
StringType = 'str' | 'str[' StringRange ']'
StringRange = string [StringRange]

Leading to one example, meta information schema file like:

File:
tu r string
ru r string
axis_ordering o 3*string
Object:
special_type r string[building street bridge]
infos o string*
buildingyear o int[1990:2022]

Based on such a meta information schema implement:

• a parser
• a validator

Where the validator is used to validate a GeoObjectFile or can be injected to a GeoObjReader, GeoOffReader or GeoPlyReader.

Such a validator could have the following signature:

class SchemaValidator:
  def __init__(file_schema: Dict[str, Any], object_schema: Dict[str, Any]):
     # Todo
  
  def validate(file: GeoObjectFile):
     # Todo
  
  def validate_file(key: str, values: List[Any]):
     # Todo

  def validate_object(key: str, values: List[Any]):
     # Todo