Skip to content
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 45 commits into from
Jun 14, 2019
Merged

Proof of concept for an API #13

merged 45 commits into from
Jun 14, 2019

Conversation

balazsdukai
Copy link
Member

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

  • Started a proof of concept for an API. You can read about the first struggles in docs/design_document.ipynb. Mainly implemented in models and a few additional methods in cityjson
  • A bunch of tests for the API
  • Started documenting the functions and wrote an API tutorial https://tudelft3d.github.io/cjio/

Changed

  • When --indent is passed to save, tabs are used instead of spaces. Results in smaller files.

balazsdukai added 30 commits May 2, 2019 13:13
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.
@balazsdukai balazsdukai merged commit c8f6cb2 into develop Jun 14, 2019
@balazsdukai balazsdukai deleted the feature/api branch June 14, 2019 13:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant