fhooeaist / geofiles Goto Github PK
View Code? Open in Web Editor NEWEvaluation of file formats in the context of geo-referenced 3D geometries.
Home Page: https://fhooeaist.github.io/geofiles/
License: Mozilla Public License 2.0
Evaluation of file formats in the context of geo-referenced 3D geometries.
Home Page: https://fhooeaist.github.io/geofiles/
License: Mozilla Public License 2.0
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
.
The coordinate list that is created by the GeoVRML writer contains vertex duplicates. This should not be the case and has to be fixed.
Add a reader implementation for Gml. Add the information that this is connected to semantic loss.
Add a reader implementation for GeoVrml. Add the information that this is connected to semantic loss.
Add a possibility for writing to a string instead of a file
Add a minimize() function to the GeoObjectFile
class, which will combine all GeoObjects
to one, as required for e.g. GeoOFF
or GeoPLY
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.
Add a reader implementation for GeoJson. Add the information that this is connected to semantic loss.
Add another column to the feature comparison according to the geographical extent information (for cityjson, geoobj, geoply, ...)
Add origin support to CityJSON using the transformation
object
Add a possibility for calculating the geographical extent of a GeoObjFile
, considering the included transformation and origin information.
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.
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:
Add support for parsing strings representing e.g. 'geoobj' file content.
Also if CityJSON and GML are already supported, extend the support to CityGML.
Add a reader implementation for CityJson. Add the information that this is connected to semantic loss.
Recreate: https://fhooeaist.github.io/geofiles/
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.
Adapt the GeoOFF and GeoPLY writer implementations to require single objects.
Add a reader implementation for Kml. Add the information that this is connected to semantic loss.
In 2.0.0 we introduced meta information for objects.
Should be extended to also have file based meta information.
Define default meta information that can be used in the proposed file formats e.g.:
The GeoObjFile
domain class may contain geographical extent information. Forward this information to CityJson if it is available.
Update the Feature Comparison based on the table of the associated paper.
Add OGC support (https://github.com/opengeospatial/ogc-feat-geo-json)
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.
Transformation information was added to CityJsonWriter in Issue 28.
These changes also have to be introduced to the CityJsonReader.
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?
This issue provides visibility into Renovate updates and their statuses. Learn more
These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
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
Extent the header line by the following pattern for transformation and origin support:
[t][r][s][o]GeoOFF
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
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:
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.