OpenStreetMap
The first coding period of the Google Summer of Code has begun! So far, I’ve worked on a draft for the REST API, which you can see here, so that we can iterate on it, and 3D visualizers for OSM can start planning their implementation. I’ve also designed all the web pages that will be used for the 3D Model Repository, using Bootstrap, as can be seen at the end of this entry.
I have also changed how the nightlies were generated from my original proposal, which defined them as a collection of the most important models, to having all the models in the nightlies, so that you can get all files from the repository by downloading all of them. They will be in separate size-limited chunks now, to make it easier to download versus a big file.
Now that my semester is over, the pace should pick up quite a bit, with the full design of the database schema, integration of the web designs into Django and OAuth authentication planned until the end of the month.
Finally, we now have a (possibly temporary) repository on GitLab!
New design of the homepage, with the new alternative model panel design.
User page design, notice the presence of the user’s description, a list of their models, their latest changes to the repository, and their avatar. The pagination at the bottom was omitted.
API documentation page design.
Discussion
Comment from -karlos- on 16 June 2017 at 18:57
Hi! Good to know, its going on. I am waiting for the moment, the API is online.
To me as an rendere programmer, the Web-Interface is important but secondary. I need the api to be usable with my code. Your reporitory is not exclusively for OSM, is it? But I see it as the primary use anyway. So the main question is:
How to tag in OSM, to place models?
It great to have so much ways to find models. The access of an 3D renderer has to be quick, simple and save. The repository should have an unique ID for each model of course. But shall we use it in OSM? I thought about an String, or three: Country, city, building-name. This 3 data should be part of your database as tags, will it? So both ways could be used in OSM, the ID and the tags.
The second task, is to “erase” the original OSM-Buildings and Building:parts form the 3D rendering. We could list the OSM-IDs in your data base or place an tag to each OSM-Object.
To add the GPS to the model is a good idea. But in OSM, there should be also a node as the exact position of the model. That node will have a tag as reference to the repository.
There are more points to think about:
The upper comments are about unique buildings. For object like street lamps, or sequences of townhouses we have to think different: direction and even size may be given as tag in OSM.
The API looks ok. ZIP seems to be no problem for javascript, I am using. The models may also include bitmaps/textures, may they? An Eifel Tower or an electric pylon with less load for an real time render may be a simple shape and the grid structures as textures.
My idea was to have that repository permanently mirrored at the servers of all using 3D renderer. That would offer safety by redundancy, load distribution, and easy access for the render clients. That may be an option for later versions.
Comment from n42k on 30 June 2017 at 16:03
Thank you for your feedback, -karlos-.
The web interface is meant for the modelers, so that they can upload models to the repository. Of course that 3D renderers will only use the API. The repository is not exclusively for OSM, yes.
Tordanik is currently working on a draft on the tags to be used here. We have favored this id-based approach as it’s more generic versus your country, city and building-name tags idea, which would work very well for specific buildings like the Eiffel Tower, but encounter issues when used for generic models like benches and power poles.
We followed your idea of placing a tag to ignore the rendering for each 3D model in the draft above.
The GPS coordinates of the model sent back through the API are for convenience only. They’re the GPS coordinates stored in the repository, to be used for finding models on a map in the web application easily (such as going to Italy and finding the Leaning Tower of Pizza) in a slippy map. It will also be used, of course, for the range based search in the API. The coordinates stored in the OSM node should be used.
The model can have a different size, direction, and source point. Users will be able to specify the units used for the model, how it’s oriented, and a translation to apply to the model before applying any other transformations.
LOD would be an interesting idea, but it has to be skipped for now due to a lack of time, maybe after GSoC ends it can be considered.
Yes, models can include textures, both for the savings you mention and for allowing aesthetically pleasing models.
As for your last idea, about mirroring the repository, we will offer a nightlies files that you can download, which includes all the models and their metadata, so that you can do exactly that. Mirroring is a great idea and should ease any performance issues that might arise in the repository.