the question raised: Shall 3D renderer use default values, heights for example?
We should tag for rendering, but not for renderers like F4map.
Unfortunately, to render 3D we are forced to use default values, like for building- or fence-heights.
Are there defaults for 2D rendering? Examples? How to render a highway=yes? For 2D, editors have a lot of checks and we have habits, given in the Wiki. Mappers get kind of forced to add 2D tagging. We do not have and want it for 3D.
F4map long time was the orientation. Now other editors break us free. But what options do we have for defaults?
We could show, whether a value is tagged or the default is used.
We could make the defaults as parameters.
Default could be unique values, depending of the type or even algorithms.
There could be âmap stylesâ for 3D rendering (F4, OSM2World, Urban Eye, user defined)
We could agree about a set of heights to have the same result in âallâ renderers.
Shall we try to discuss this for the âhightâ of buildings, trees etc.?
Just as an example: In OSMgo.org, if no height or levels tag is given, the building default is calculated by the root of the footprint. Looks nice, but is a fake impression.
In discussions like this, I feel like a complete idiot. Maybe I am stupid indeed.
I absolutely donât understand what the aforementioned âa correct way to fill the Geo-Databaseâ means, or what âDo [not] map for the rendererâ means.
So, I drew a way and added the tag building=hut to it. Why canât this renderer render a hut? What the hell else does it need? Also, in some other place Iâve added building=skyscraper. Why does this renderer draw me a hut with just 2(!) floors?
Shall 3D renderer use default values, heights for example?
Framed like that, the question doesnât make any sense at all. Of course, a 3D renderer has to use default values.
A 2D renderer displays objects using conventional symbols and colors, but a 3D renderer canât do that. It canât just render a âgeneric treeâ in response to natural=tree. It first has to decide what it is: an oak, a pine, a birch, or an aspen. The same goes for height. If the height tag isnât specified, it has to pick some height. If only for the simple reason that zero-height trees donât exist in nature.
Generally I agree, that a renderer, especially one which is part of an osm editor, shouldnât go completely off the rails and just make things up.
Probably it means that there shouldnât be too much random generation. And there are nuances. For example, if a default roof type, like gabled, is pulled in for a certain type of building, user canât just add roof:orientation=across. The roof:orientation tag shouldnât have any effect if roof:shape isnât defined expicitly. Probably there are other caveat like this.
Simple answer to your question is âDepends what is the purpose/vision of that renderer designersâ. There are two main ideas that I see:
one might want the renderer that makes a nice looking 3d model always, even if data is lacking (and it is basically always lacking in practice ). To do that, it will assume some defaults when explicit data is missing, which might be imprecise, but will look relatively fine. It might also decide to ignore explicitly specified values if they look unrealistic (e.g. if some building=house has height=2100, they might assume that is mapping error and that it might be ele=2100, or ignore such suspicious values completely like they werenât specified).
In such renderer, e.g. if building=house does not have building:levels specified it might assume 2 or 3, or same number of levels as neighbouring building, or average of neighbouring buildings, or something something similar which will quite possibly be wrong, but not be detectable as wrong to the casual user.
One might want to use such 3d renderer if for example theyâre making a flight simulator game. Or,
one might want the renderer that only renders explicitly specified values, and does not assume anything and instead throws a visible warning for every missing piece of information that it needs for precise unambiguous rendering.
Such renderer might decide to render a building=house which does not have building:levels specified as a 100-stories high building in blinking red with text rendered over it which says "Error! building:levels=* not specified! Fix this!"
One would want to use such renderer e.g. if theyâre an OSM mapper who wants to micromap some area with precise values so the area is then rendered in all renderers realistically with correct data, and wants to know what data is missing and should be collected.
One could even have a setting in the same renderer which lets the user choose which mode they want (but that is more work for programmer, obviously, and they might care about only one of the use cases above and not both).
Err, âit would need workâ? Like, enormous amounts of it?
If the renderer draws all building=* the same regardless of the value (i.e. hut and skyscraper looks the same), that required like maybe 5 hours (or whatever) to draw how any building would look like.
But building=* tag has about 8513 different values. If one would like to draw each of those 8513 values to be different looking, one should of course first research all 8513 types of buildings, and draw a model of how each of those should look.
If each building still took only 5 hours to draw (and no time to research, for simplicity), that would be still be 42565 hours instead of just 5 hours. If you were drawing buildings 8 hours each day, it would take you about 15 years just to draw all the buildings.
And buildings are just one of many thousands of things that should be drawn in a 3D renderer.
TL;DR: it takes time and work to draw different things. The more things you want to look different, the more time and effort must be invested. And time and effort are a limited resource (even if you had infinite amount of money to throw at it, which you usually donât).
And if one is using 3D renderer which works (primarily, or even only?) as a JOSM plugin (which I assume UrbanEye 3D might be), I would expect that most users of it would want that option for hopefully obvious reasons (i.e. theyâre editing and trying to get all information correct, and not âmade upâ which would hide missing data and thus work against their work).
But even then, there could still be an extra button (or non-default preference) named âDayream-mode beautifyâ which would guess missing data and show nicer rendering. But the default should still IMHO be to only show the data the user has entered in JOSM, and somehow warn (visually) about missing data.
In that specific case i meant something else, sorry for the confusion. I try to explain, what i meant:
You should not refrain from tagging something just because some renderer already assumes this tag (incidentally correctly).
The thing is, osm is a database, not a renderer. A renderer can do whatever they want. So, why do i say its a database? Zkir mentions a skyscraper - i donât have a problem with a renderer simply assuming a height for the skyscraper. The range is from 100meters to 830meters. What do you take? A random renderer should take whatever they want in my opinion. What they think they like. They could even go the router âif there is no data, randomize the height of scyscrapersâ to be honest.
Urban Eye 3D solves this problem! Mappers and 3D building enthusiasts can now preview their edits directly within JOSM before commiting changes to OpenStreetMap.
So while âsomeâ assumptions are usefull, i donât think are usefull, i donât think too much should be made. A house with two stories and a flat roof was always a sign to me that there is data missing. But i never thought about fences or trees for example and iâm not sure what a solution could be. Or even if nothing makes sense. Like a green rectangle for missing information and getting a âbetterâ picture shown when additional data comes in.
I know, that doesnât make anything easier, but i hope i better clarified what i meant.
Urban Eye is an editor-helper! For Buildings only? I even wondered why it shows trees at all.
Itâs fine if it also makes a nice view but it should have a switch, a nice_mode and show_tagging-mode. I like the idea of explicitly rendering missing tagging. We could have an odd no-roof-shape get rendered. Or red trees. But we also may have defaults, according to the tree type - in the nice-mode. The same for hugs and skyscrapers. In tagging mode, a fix height is ok, or a colour, or a graffiti symbol at the walls for missing tagging (optionally even in nice mode).
To set default level to 1 for a garage provides a better impression even while editing - IF it is marked as âunder-taggedâ in tagging-mode.
There should not be any real random generation for tagging values, not even for a nice view. Algorithms like using neighbours value is fine.
Ignoring unrealistic tagging is a lightly different topic, but another option-setting for a renderer. A tag checker doesnât need to be a 3D renderer. But like missing tags, a backup reaction is needed.
OSMgo shows unsupported colour strings as sky blue and unsupported area types in red.
100-stories may be a bit unhandy because most times, the editor does not know the correct values of a big area and I donât assume, the editor is used outdoors.
The nice-mode would even have a sub-mode F4map to mimic their defaults. But that would lead the user in the wrong way.
Guys, I do not get why you are constantly talking about missing tags. height (and building:levels) is just one of the ways to convey building tallness. There could be other ways also. Moreover, in most cases height is completely speculative, not based on any measurements.
Basing on such logic, I should rather exclude building=yes (instead of building=something) from 3D rendering, because the most important information about the building â its type â is missing!
3D rendering is just a sidekick of OSM. There are city areas with great 3D tagging, and a major countryside without. But I donât feel good, âforcingâ users to tag for it. To motivate, we need a âniceâ rendering, but with strong hints about missing tagging.
Levels and roof types, colours and materials can even be done by armchair editing, if the 3d editor offers street view.
For height measuring there are smartphone tools. An on-site 3D/2D editor is one of my dreams.
What other ways for tallness do you see, do you think, we should support?
First of all building type, i.e. value of the building tag itself, like this: smart defaults. Despite @Matija_Nalis 's calulation above, it did not took me 15 years, just 3 days
I (at least) was not suggesting skipping rendering such building with lacking attributes at all, but more of indicating missing attributessomehow â e.g. by putting a specific pattern or different color on building lacking some significant data (significant for 3D rendering), like when roof:type or building:levels/height is not specified at all.
Because, as an editor helper, is matters very much whether UrbanEye3D guessed e.g. building:levels=2 (using its smart defaults database), or whether the mapper has manually specifiedbuilding:levels=2 OSM tag â because some other 3D renderer might assume different defaults, and break the display there even if looks fine in UrbanEye3D.
Thus it would need to know at least whether some of those values were guessed via that âsmart defaultsâ database and render one pattern/color (e.g. red); or whether all parameters from that âsmart defaultsâ database were overridden by explicitly specified OSM tags (e.g. keep current grey).
Renderer might also choose to indicate visually which data is missing to be nicer (e.g. just color roof as red if roof:* data is missing, or just color side walls as red if building:levels data is missing), but that would be a cherry on top and not really needed.
That way, mapper would know at a glance which data is missing â and thus which data might be guessed differently by different 3D renderers (which is a situation much 3D mappers often want to avoid, i.e. they usually want their work to be correctly rendered everywhere, and not to depend on luck and random educated guesses alone)
On a related note, Iâve originally used roof:orientation only for across and for otherwise ambiguous along but according to Rendering, some renderers do use across as the default so mapping the orientation regardless as a result.
I get angry about that: âOsmbuildings.org changed the default focus to acrossâ.
On the other hand, it shows, how important tagging is.
You see it at once, if it is wrong - if you have a picture or knowledge. But not if the tag is missing.
In this case, the wiki page should define a default!
Because you canât force, not even motivate 3D tagging that much.
But I am not sure, if a renderer really uses a wrong default. Because the definition for âalongâ is difficult. âthe longer of two building edgesâ is not at all a final definition. We need more text.
What, if there are more but two edges?
What, if the âshorterâ edge is only a part of the longest side, but split by detail nodes?
âŚ
I assume @Tordanik could provide more details. As far as I know, OSM2World rotates the footprint to all way parts, puts it in a rectangle and checks the with/height relation. The most unequal relation is along. Something like this should be part of the âdefaultâ.
Somme simpler rendered only check the longest way part and the footprint relation for it. If âwrongâ, the orientation is rotated by 90°.
Iâd rather see the effect of a missing or wrong value than an assumption. A flat outline instead of default 2 level building, a 2m stick for a tree with no height, circumference or crown diameter, a flat roof instead of a shape (I know flat can be true too).
An then can and open DEM be applied? (Iâve yet to try and tag for a building on a slope, but maybe somedayâŚ)
Perhaps more complex for the plugin designer, but can there be an overall option to turn off or on the application of defaults?
I assume, we all agree to have this render mode, you wish. But als a mode to have a nice view, usable for games etc.
We canât write a wiki page, what a 3D rendere must do, but what he may do, what we agree about. We can collect ideas, how to make missing tags visible; and ideas how to replace them by defaults. We also can maintain a table, what existing 3D rendere do already. Shall we?
(1)
If you want to find and fix missing building tags, JOSM has a very cool feature called Filter. Itâs super handy to use, and the best part is you can choose yourself which tags you want to fill in ânot something hardcoded and what we need to argue upon. For example, you can find missing roof:material etc.
Address?
Building type?
Levels?
Roof shape?
Building material?
Roof material?
(3)
For DEM, absolutely nothing is ready yetâno plugin, no tags. If you want to place buildings on sloped terrain, the tags need to account for different numbers of floors on different sides.
(4)
ideas how to replace them by defaults
What would help us, in my opinion, is to create S3DB version 2.0 â not so much with new features, but with default values ââfor old ones. But that would only be worth pursuing if the F4 guys agreed to participate, and I doubt thatâs the case.
We also can maintain a table, what existing 3D renderers do already. Shall we?
Iâd love to have an updated version of S3DB, Iâve noticed quite a few gaps and possible improvements over the years. But yes, we would have to get the developers of several renderers on board with that effort.
(Iâve yet to try and tag for a building on a slope, but maybe somedayâŚ)
