Hopefully the new update will be released tomorrow.
Thank you too ![]()
Hopefully the new update will be released tomorrow.
Thank you too ![]()
While playing around with those roof-stuff I came across a limit to zoom in any further, though, where I would have liked to zoom in further. Not sure whether the zoom is limited on purpose?
Again, pretty awesome tool! Huge motivation to add all those details👍
If you zoom too near, the picture become too flat and too boring ![]()
Bricks, glass, tiles etc and horizontally sliced/stacked buildings looking sweet in the latest v. 1.4.0
Yep, 1.4.0 is out! This release introduces some nice enhancements:
A new plugin setting allows you to enable or disable the simulated Ambient Occlusion effect.
In my personal opinion the picture without it is boring, but now you can choose.
Shortcut: Shift+Z
The plugin now automatically infers building:colour and roof:colour values from their corresponding material tags (building:material, roof:material) when they are specified.
(pic from @Cebderby post above
)
Support for two new roof shapes has been added:
* roof:shape=side_hipped
* roof:shape=apse_gabled
side_hipped is very common shape, strangely it was not included into the original S3DB spec.
apse_gabled is not so common, but very useful for the church architecture.
roof:shape=crosspitchedThe tag roof:shape=crosspitched is now recognized as a synonym for roof:shape=cross_gabled.
Apologies, I missed the 64 bit encrypted password for mapping of apse_gabled :-/. Mapped a 1 piece church in the middle of a vineyard with what i think are the base needed tags, but only get a shallow gabled across. Is it the building still needs splitting in 2?
… And Yes, the main body needs the gabled roof tag and the half round end needs a separate apse_gabled. It seems impervious to any roof orientation or direction, the round edge is assumed the low round edge.
If one puts apse_gabled on the main body, the shallow side gable returns.
Long as we understand the composition of the sauce we can work with that.
Thanks a many.
PS I like the roof tile colour default. Close to the orange and orangered which we have here in large quantities.
Yes, you need to split the building into two parts, and put roof:shape=apse_gabled on the apse part.
the remaining part can be roof:shape=apse_gabled.
I may also support roof:direction for this type of roof, but only if someone asks for that ![]()
Went back to a real life building and got it down to 3 objects, the whole for the 2D world and the 2 building:part for the 3D world, the apse wall lime white (breaking out the champouse)
Speaking of the F4 de-throning, “Le roi est mort, vive le roi!”
It renders exactly as specified: the apse Way: 1426256210 | OpenStreetMap has building:colour=white, and the main part: Way: 1426256211 | OpenStreetMap has building:material=brick
![]()
Going by the book, I’d be inclined to rename apse_gabled half round part to just apse or at least make it a synonym, since what’s below is a described in this wiki page. The gabled suffix is kind of superfluous now. At any rate there’s only one entry in TI, so far.
I love your work on this! I soo would like to use it!
With StreetComplete (roof mapping), the end result is often kind of wrong because the roof:orientation is not asked for also. This plugin would be ideal to make these kind of corrections.
StreetComplete is an Android App, written in Java or compatible with it. So it may be possible to integrate this viewer (and add more tagging options)
StreetComplete is an Android App, written in Java or compatible with it. So it may be possible to integrate this viewer (and add more tagging options)
StreetComplete is written in Kotlin, not Java. It is true that it is currently Android-only, but we are migrating to it being a Kotlin Multiplatform app. We are pretty far in this migration, this means that we cannot use Java dependencies.
For example, the app used to use Simon Poole’s OpeningHoursParser for parsing OSM opening hours strings, but since this is a Java library, I had to create a new osm-opening-hours parser in pure Kotlin so that it is available off the JVM platform too.
Using Urban Eye 3D would only become an option if the core part of Urban Eye 3D (the creation of a 3D model data structure) was converted to pure Kotlin and published as a multiplatform library.
However, the last time I looked into that (in context of maybe using osm2world if it was available as a Kotlin lib), the key blocker here was that for Compose Multiplatform (the UI framework we are migrating to), there is no multiplatform 3D-rendering API / library available - i.e. some kind of 3D model viewer. And this alone would probably already be a large undertaking (to do it oneself).
Edit: Which is why at this time it is not worth considering.
@westnordost, thank you for the kind words, it’s motivation for me to make the next version of the Urban Eye even better ![]()
I think StreetComplete is quite nice enough already. Not every app have to be a 3D viewer.
Plus, very often, rooftops are much easier to see from satellite rather than from a street.
Also, even the core part of the plugin is dependent on certain java libraries, like JTS and Campskeleton
Maybe AI will become strong enough one day to rewrite everything in pure Kotlin from a single prompt. ![]()
So as I assumed Codlin is compatible like JavaScript and TypeScript and could call libs like JTS.
I did not know, CodLine can build to iOS. Only JTS will not run on iOS.
Gerat: I will be able to use StreetComplete with an iPad/Phone “soon”, great!
As a multi-platform 3D renderer, I only know WGPU. It could be used by a “C” interface by CodLin, I only assume.
Yes, merging 3D into StreetComplete may be too much. My dream-idea is, to have a mobile AR app, augmented by OSM data and even with editing features.
But I would like to see and contribute my time to have a CodLin-Lib for 3D rendering, usable for OSM2World, UrbanEye3 and more. With JTS, it would not be multi platform, except we will find a solution later. Shall we start an experiment togehter?
Did a couple of big buildings in Pollutri, this one with crosspitched ends and hipped sides and the left bottom corner.
The dead king was speaking from the grave and inserted this rendition (at the time of only having mapped the long part).
The long ends are proper gabled ends (The big blob in the background has a ‘basilical’ roof, truly named the Incomplete church of the Madonna del Piano and will add 3 building:part of centre gabled and 2 skillion sides as that no one but the 4D wiki has mastered :o))
Back to the main course, the below is what I get with both the tag values of cross_gabled and crosspitched (literally copied from the quote above) It’s a truly popular roof shape here, reminding me of the struggle to get the apartment blocks right in Lanciano.
Am hoping it’s just some typo somewhere in the chain (my weakest link).
Tried all possible variations on the 2 values but UE3D wont spill the beans. Something in the plugin and 1.4.0 is definitely in me JOSM.
Meantime whipped out the ‘incomplete’ church… no bell-tower. Had not thought it was that simple with the buttresses but it was. (not created a type=building relation… seems to have become a superfluous function, ‘just’ 15 parts here.
Now an arched door and arched and circular windows the real thing has and we’re really talking. As with the church in Moggio a raised Façade.
Grass is green, the left flat roof covered with. ‘grass’ as roof:material is definitely a thing in inner cities… works as a air cleanser.
Need to work on that front back wall as is typical here that’s raised equal or higher than the gabled roof… will do in next iteration.
You’d like to be able to represent the archway and circular windows with building parts? Maybe, if we ask very nicely, Zkir can do some experiments with UrbanEye to see if my little proposal is technically feasible ;)
I would not mind to have a basic demo.
Our roof shapes are plain constructive. The base shapes have to be “subtracted” 3D geometry from 3D geometry. There are libraries for this. It is a level up in complication anyway.