-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proof of concept for an API #13
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Conflicts: # cjio/cjio.py
At this point I'm not sure how to link the semantic objects to geometry boundaries without duplicating the geometry. Duplicating the geometry is a very bad idea because I would need to keep track of the changes to the semantics/geometry at several locations, which will fail for sure. Ideally, I would use the same linking mechanism as it is in the data model, thus the semantic objects would just point to parts of the geometry boundary. The other question is, how will it be possible that the user works with a single citymodel, and cjio simply changes parts of that citymodel. Instead of passing each cityobject into a distinct object and then having to manually combine the citymodel. So somehow I need to keep reference to every cityobject.
Explore how could it work if there is no SemanticSurface class, but the semantic information is stored in the Geometry class and the semantic surfaces are extracted on demand by a Geometry.get_surfaces() method. However, this alternative does not allow to get the children and parents of the individual semantic surface objects.
Store the SemanticSurface objects in a plain dictionary, because there are not methods for them anyway, so we don't need the overhead of having objects.
+ level of detail + semantic surfaces + cityobject attributes
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
An attempt on creating an API for cjio that allows easy*-er* manipulation of 3d city models in python scripts. A summary of the development is written in this tutorial: https://tudelft3d.github.io/cjio/cjio_tutorial.html
Added
docs/design_document.ipynb
. Mainly implemented inmodels
and a few additional methods incityjson
Changed
--indent
is passed tosave
, tabs are used instead of spaces. Results in smaller files.