Closed bennlich closed 8 years ago
Hi Benny, Unfortunately this is not really new. Though I fixed some z-ordering issues, problems are still present (and known). What I'm still looking for is a safe algorithm to determine the proper order of buildings. Its not as simple as it seems. I'm also considering a face-by-face algorithm but not decided yet. Any ideas are welcome!
Regarding size, depends on where the data is from. OSM, CartoDB, other? Ist height in feet? :-)
Hey, Jan. Here's a picture of how the exact same dataset rendered before I pulled new changes:
The buildings are much shorter, and the occlusion seems correct (or is it maybe that the default transparency is just higher?) Also, the rooftops were automatically colored based on the walls. Here's what that same patch looks like in the latest version of OSMBuildings with the roofColor attribute added manually:
Did you make any recent(ish) changes to the z-ordering algorithm?
Regarding height: I've changed a correction factor which was not needed for OSM anymore. Looks like you are using a custom data source (probably height in ft).
Occlusion is the same, just noct that obvious due to transparency.
roofColor behavior changed from beeing like a bar chart towards more controlled building attributes. You now need to set it explicitly.
Ah, k. Should height be specified in meters? It is a custom data set.
On Wednesday, June 26, 2013, Jan Marsch wrote:
Regarding height: I've changed a correction factor which was not needed for OSM anymore. Looks like you are using a custom data source (probably height in ft).
Occlusion is the same, just noct that obvious due to transparency.
roofColor behavior changed from beeing like a bar chart towards more controlled building attributes. You now need to set it explicitly.
— Reply to this email directly or view it on GitHubhttps://github.com/kekscom/osmbuildings/issues/34#issuecomment-20037074 .
You can specify what you want, but the engine needs a base. As metric system is standard for OSM I've chosen this ;-) Just make everything a third.
-----Ursprüngliche Nachricht----- From: Benny Lichtner Sent: Wednesday, June 26, 2013 7:49 PM To: kekscom/osmbuildings Cc: Jan Marsch Subject: Re: [osmbuildings] Building occlusion (#34)
Ah, k. Should height be specified in meters? It is a custom data set.
On Wednesday, June 26, 2013, Jan Marsch wrote:
Regarding height: I've changed a correction factor which was not needed for OSM anymore. Looks like you are using a custom data source (probably height in ft).
Occlusion is the same, just noct that obvious due to transparency.
roofColor behavior changed from beeing like a bar chart towards more controlled building attributes. You now need to set it explicitly.
— Reply to this email directly or view it on GitHubhttps://github.com/kekscom/osmbuildings/issues/34#issuecomment-20037074 .
— Reply to this email directly or view it on GitHub.
Okay, coolio! Thanks for all of the prompt replies.
As for the z-ordering algorithm, my intuition is that the only way to do it safely would be face-by-face (assuming the alternative is building-by-building?). For example, if you have a donut-hole building inside of a donut building, the donut-hole could occlude part of the donut, and the donut could occlude part of the donut-hole.
Perfect example. Face-by-face makes the code a lot more complex but ideally the drawing gains speed. I just need a point to start with...
-----Ursprüngliche Nachricht----- From: Benny Lichtner Sent: Wednesday, June 26, 2013 11:19 PM To: kekscom/osmbuildings Cc: Jan Marsch Subject: Re: [osmbuildings] Building occlusion (#34)
Okay, coolio! Thanks for all of the prompt replies.
As for the z-ordering algorithm, my intuition is that the only way to do it safely would be face-by-face (assuming the alternative is building-by-building?). For example, if you have a donut-hole building inside of a donut building, the donut-hole could occlude part of the donut, and the donut could occlude part of the donut-hole.
— Reply to this email directly or view it on GitHub.
I added a quick fix for most occlusion cases. Please give it a try.
Sorry this has taken me so long to get to, Jan! I'll give it a try soon.
On Thu, Aug 8, 2013 at 11:51 PM, Jan Marsch notifications@github.comwrote:
I added a quick fix for most occlusion cases. Please give it a try.
— Reply to this email directly or view it on GitHubhttps://github.com/kekscom/osmbuildings/issues/34#issuecomment-22378048 .
Yes! The occlusion is much better! How'd you do it? I'll let you know if I find any more culprits.
Honestly, a fix is unlikely anytime soon, if at all.
Howdy! I just pulled the latest changes from the repo, and it looks like the z-indexes of some of my buildings are behaving strangely. I took a couple screen shots:
Notice in the bottom image how the left teal building moves in front / on top of the shorter blue building. I hadn't fetched the latest repo in a while, so I'm not sure which commit is the culprit.
I also noticed that many of my buildings appear much taller than they used to.
I'll start looking at the new commits.