Request for Feedback on 3D Model Repository API + content guidelines

General talk
,
1

The 3D Model Repository (3DMR) is a place to upload 3D models for use with OSM data. It is hosted by FOSSGIS, the German local chapter of the OSMF. The project is currently undergoing major renovations thanks to @Ayush_Dhar_Dubey. (See his weekly progress updates.)

Our overall plan involves:

  • models in single-file glb (binary glTF) format
  • suitable for real-time rendering
  • permissively licensed and (like OSM) with no requirement for individual attribution.

We want as many OSM-based 3D renderers as possible to use the 3DMR to augment scenes created from OSM data with 3D content. After all, there are limits to what can be modeled in OSM itself with Simple 3D Buildings and similar tagging standards.

To achieve that goal, we want to make sure our content and API meet your needs. So we’d like to hear your input at this early stage, especially if you’re a potential data user or contributor!

For example, interesting topics for feedback could include (but aren’t limited to):

  • Which guidelines should be give to contributors to ensure that models are suitable for performance-sensitive real time rendering applications?
  • Does our proposed link mechanism of adding 3dmr=* tags to OSM elements work for you?
  • Do you prefer using the API or nightly download dumps? Is anything crucial missing from the API?
12 Likes
2

Hi fellows 3D renderer!

I love the change to glTF/glb files. We could even support animations like rotating Dutch wind mills.

The glb files should not have external references. All textures etc. must be in the GLB-Zip.

I did not think about the “size” yet. Our hardware gets better and can show a lot. But there are still old devices we also should support. Better a low res model but nothing, isn’t it?
I just got an idea:

  • We should add the “size” of the file in the file data api, so an app can decide not to show high res models.
  • And we could enable multiple “sizes” for the same location. May be according to the concept of LoD 0 to 5.

My OSMgo.org uses 3dmr.eu already and I am happy with the API, as it is now. But reconsidering, I should it.

The documentation for uploading may not be that good. I should take a look.

I use the API for downloading the models. And the UI for upload. And API for upload will hardly be needed.

Guidelines, my spontaneous thoughts:

  • The size should be im metric meters. But we should add the option to set a parameter “scale" factor while uploading.
  • It would be nice, if the orientation is as in the real world. That’s rater not the case, so we need a parameter to set a direction offset while uploading.
  • A glb fiel has a virtual zero point (3D) It should be at ground level and at that geographical position, the node in OSM is placed to. We could consider to support north/east offset parameters in meters.
  • Models should only include the building, NOT some area around, usually. There may be exceptions like the Apple Park? (See: 3dmr=31)
  • Models should not render the walls from inside do reduce the load of the rendering, except they contain indoor structures.

The UI should show all parameters. And an app needs to get all of them by the API to place the model correctly.

But this parameter set is only valide vor single instance models, like the Eiffel Tower. Well, even it will exist at other places like theme parks or exhibitions. The same is given for models like a wind mill or a street light. In this case, all this parameters need to be in the OSM tagging value of the “3dmr” tag. We need a detailed tag definition in our help and the OSM Wiki.

Just by downloading the models of an area and show them in the rendered OSM world will not be enough. Some tagged buildings need to get replaced by the model, means, not be rendered. To do this just by the extend of the model will be questionable. I propose to have tags like “3dmr=" and “3dmr=yes” or “replaced”. This should work on a relation to of course. With the we do not need to scan the 3dmr server but directly download the data and the model. For model instances, the tag may also contain the parameters. I.e.:
“3dmr”=“2;lat=-12.34;lon=45.67;dir=180;scale=1.0;north=0;east=0”
If lat/lon is not not given, the position of the node is used. May be we need a doc vor upload and a doc for app implementation.

The API:

It is not for glb files yet. “filelist" will be obsolete. It would be nice, to have a proposal online. May be together with an Beta test version of the server, like at “beta.3dmr.eu”

Tags and categories are good for the UI. The renderer may have an option to show all data in a pop up.

What is aint:pageid ? From a defined zoom level?

More thoughts:

The map page shows markers. They, and the model page may offer to open a 3D renderer, using 3dmr.eu at the position of the model.

I see 3dmr=31 using non Engish categories and tags. I would not support this.

-karlos-

1 Like
3

Thank you, your post touches exactly the kind of topics I was hoping to discuss. :slight_smile:

Exposing more statistics about the model through the API is a good idea. We’ll have to see how easy it is to implement, but it would enable data consumers to automatically decide which models to include in their rendering.

I do agree with those conventions. However, I would personally go further and require models to follow the conventions, rather than permit non-standard scale/orientation/offset. (Or if we do offer such fields during upload, use that information to automatically fix the model before it is saved in the repository, e.g. by rotating it and scaling it to the correct size.)

To give people a better chance to get these conventions right, we should make things such as scale and direction visible during upload.

I’d rather not ask mappers to add this kind of data into a single tag value. As far as I can tell, all parameters besides 3DMR ID can be derived from established OSM tags such as direction=* to describe an object’s orientation. For scale, tags such as height=* can be used. (Although, as I said before, I would prefer if the model file is correctly scaled in the first place.) Are there any required parameters which we cannot get from the geometry and tags of the OSM element?

This is a tricky topic. We do need to include the ID of the model that a feature gets replaced by. After all, a data consumer will most likely not use every model, and if they don’t use the model which replaces that particular OSM object, they will want to render the OSM object. Ideally, this would be rarely because the model should be for exactly one OSM element, but I can see that this is not a realistic expectation in all cases. :thinking:

I’m inclined to agree. In general, I do believe we will have to individually look at the existing models and clean them up in various ways.

This if from the other thread, but I’d still like to ask you about it. My current thinking would be to use the same mechanism to place models no matter whether they are used only once or more than once. That is, the Eiffel Tower would have a 3dmr=* just like more commonplace objects, and that’s how you know where to place its model. What’s your reason for treating it differently?

4

I’d really like to see 3DMR to switch to wikidata IDs for identifying these kind of unique buildings. wikidata IDs are in such wide-spread use in OSM by now that this is feasible. You would save mappers the work of adding/maintaining an additional tag and solve the hen and egg problem of assigning the ID.

The wikidata ID would also have the advantage that 3DMR can be used independently from OSM. The position information can be pulled from wikidata as well. This might help increase adaption.

5 Likes
5

Is part of the purpose of 3DMR to include generic assets like street lamps and trees? Maybe some sort of “This model can be used when these tags are present” + search for that might be useful?

1 Like
6

Now, rendere use generic models stored inside. 3DMR could offer them too, in variations of shape, type and LoD. Yes, we could mention tagging in the model comments for help, not so much formal fields for the start, may be later. Renderer will hardcode the model ID.

We should avoid to have an 3dmr tag at each lamp in OSM. If a town uses a certain type of lamps, the town or the region OSM Node could have a 3dmr:lamps=id. I visited Rügen and noted the power posts have different types in the “DDR”. 3DMR could offer many types and region-tagging could select the type, rendered at a place.

7

Adapting the scale, direction, offset etc. while uploading is a great idea. I just learned, some checking is done client-side. Some settings are difficult to find. So we should have a way to change them afterwards. It may be good, to keep the original model file to apply corrected settings. - A good way to check them would be a WYSIWYG 3D viewer, like OSM2World, just the new model and some more around.

Agreed, the single 3dmr tag with all settings is not handsome. For a way side cross or a bench, a direction value is quite good. A scale or height if the model is something like a three or a lantern. We must consider not to mix up with the existing tagging. The Eiffel Tower will not have a direction now. We could use 3dmr:direction too or set an extra node at the same place. But using the original node or relation will help, to “hide” the OSM parts, replaced by the model.
The tagging is not really a part of the Model Repository, the tagging will be recommend only in the description.

The Repository already has geographic positions for each model now. For the TARDIS this may just a famous example, there will be more in OSM.

Yes! And if there are more but one, a relation has to be added! The 3dmr tag(s) go to the relation (only) “keep it simple”

8

IMO those are quite welcome in the 3DMR. :slight_smile:

I’m not a big fan of that feature and would personally prefer not storing those positions. Placing and moving objects precisely is easier inside an OSM editor; I doubt that coordinates provided when uploading would reliably give more than a rough idea where in the world the object is. There’s also a legal question here: Where do people get those coordinates from? If they get them from OSM, we might have to treat the positions as a derivative database with a different license from those used for the models. I’d rather not have to deal with that legal headache.

1 Like
9

Enabling people to use 3DMR without necessarily also having to use OSM data is interesting. And I wouldn’t mind having Wikidata IDs as an optional property for 3DMR models, alongside a suitable API for querying them.

However, using indirect links through Wikidata as a replacement for direct 3dmr links has some drawbacks. Most of them are somewhat at odds with a desire to keep things simple:

  • Extra complexity: We would still need 3dmr tags for objects which aren’t unique, or for unique objects which don’t have a Wikidata item. Having only one possible mechanism for linking 3dmr models is simpler than having two. Especially if the second one involves understanding and possibly registering with a third project.
  • Unexpected consequences: It’s surprising that changing wikidata tagging might alter or break 3D maps.
  • Mismatched definitions: It’s not always clear what belongs to a particular entity. (Does the road leading through the gate belong to the gate? Does the statue include the pedestal?) Wikidata and OSM may not always give the same answer to those questions.
  • Editing conflicts: How do we prevent/resolve a situation where more than one model on 3DMR points to the same Wikidata item? If this decision is encapsulated in an OSM 3dmr tag, we can use OSM’s existing history tracking and conflict resolution mechanisms.

I do appreciate the goal of not having to maintain an additional external link in OSM. But even in the best case, we’d only move that additional link somewhere else: Instead of an OSM→WD link and an OSM→3DMR link, you would now have an OSM→WD link and a 3DMR→WD link. And that’s only if people actually omit 3dmr tags if wikidata is present, which is not what happens with wikipedia tags.

10

Doesn’t that same question arise with the 3dmr tag? Who decides which model to link to? At least with Wikidata, you could run a check that there are no duplicates.
Which goes back to my question

So the application which wants to render the structure decides which model to use. The OSM tags are entirely optional/separate.

1 Like
11

Good point, I agree that leaving the choice between multiple models with the data consumer is a nice way to look at it. In this case, duplicate wikipedia IDs or multi-valued 3dmr tags would indeed not be an issue.

12

I used the 3dmr test server with OSMgo: There is a wind turbine on the test server. This is now shown in OSMgo instead of the symbolic wind turbine. And it rotates too! An animation in the GLB file is smacked by ThreeJS.

Screenshot 2025-07-15 at 09.52.54
Screenshot 2025-07-15 at 09.52.541920Ă—863 46.9 KB

Animation (no upload of animations here? .mov .mp4)

There are some odds we may solve by editing in Blender:

  • he height null position of the windmill model is the rotating axis! We assume ground level.
  • The rotating is nor a closed cycle, it “jumps” if you watch it.
  • I have never seen that part below the gondola back side. Could we remove it?
1 Like
13

Thank you for opening up this discussion!

As someone involved in software development and 3D data applications, I really appreciate this initiative. The direction of using glTF format and providing real-time rendering support aligns perfectly with the kind of tools and visualizations we’re working on.

Regarding the content guidelines:

  • I support setting clear performance-related modeling standards, especially for low-polygon, optimized geometry with shared materials.
  • The 3dmr=* tagging mechanism seems straightforward and should integrate well with tools and scripts we already use.
  • While I like the API approach for dynamic applications, I think having nightly download dumps is still essential for offline and bulk processing.

We also explore 3D rendering and software tools like Lumion 8.3 at our software guide company and I’d be happy to share more insights from that side if it helps.

Looking forward to seeing how this develops!

— chris martin

1 Like
14

By the way, Wikidata also has items about entire classes of objects, such as outdoor warning siren models and mass-produced statues, which are compatible with model=* and model:wikidata=*. We could write documentation that makes it easier for mappers to understand how to create such items, like we already do for brands. Wikidata doesn’t require you to log in in order to create a new item.

This doesn’t need to be completely exclusive of specialized 3DMR tagging. After all, wikimedia_commons=* exists too for the times when an OSM element is so obscure that a Wikidata item about it would seem like overkill.

It might be worth looking into how Wikimedia Commons is dealing with this issue for their structured data initiative. You can now tag each photo on Commons with the Wikidata item of the thing that the photo depicts. Commons also hosts 3D models (though primarily for 3D printing purposes), so they would probably run into the same nuances as a mapper tagging an OSM element with a 3DMR model or Wikidata item.

15

You mentioned the elephant in the room.
Wikipedia „soon“ may enable to store gltf files
and so 3dmr could considered to be obsolete.
I don’t see Wikidata needed in this case.

16

I didn’t realize there was any active progress on glTF on Commons. I guess that’s what you meant by soon in quotation marks.

How would a renderer associate an OSM element with a glTF on Commons? There is wikimedia_commons=*, but it usually names an individual image or a category. As long as there isn’t an obvious best file representation of the feature, the tag would need to name a category, in which case the corresponding Wikidata item would be more usable (since you can query Commons by Wikidata item depicted) and much more common.

17

I like WikiData, but you even more. Hopping around 3 systems may be ok, if you think of a process like OSM2World: online generating 3D tiles for an OSM-3D viewer. I think of a Web-App, reading the actual OSM data from the API.

There are Perma-Links in WikiMedia. We could define a tag like “wm3d” with that link.

We have to divide common objects and single buildings. And that wm3d would only apply for buildings. Street lamps and windmills are “hard coded” in the renderer. WikiData has categories and we could add a “for OSM 3D rendering” there to find nice models. We may do this in WikiData. But I would use this referencing only while updating the renderer, not while using the renderer.

18

As I said, I hope wikidata=* and model:wikidata=* tagging can coexist with 3DMR, which is more map-focused, as well as heuristics hard-coded in renderers. To make this more robust, data consumers should prefer these sites’ APIs and structured data over unstructured, human-readable content such as categories.