Added osmb.setFlatBuildingMaxHeight, osmb.enableFlatBuildingColors, and osmb.disableFlatBuildingColors

[bennlich]

I find these functions useful for customizing how my building data is rendered. Enabling flat building colors is slower than leaving it disabled, but faster than drawing all buildings colored and 3D.

See this ticket: https://github.com/kekscom/osmbuildings/issues/32#issuecomment-16777197

[kekscom]

Yes and no :-)

I'm supporting 'disabling' FlatBuildings via max height setting. It should go to setStyle() with a probably more understandable name.

I'd rather not support a color switch but instead restore coloring in general (again). As the one batch draw/fill routine saved a lot of time, I'd suggest investigation about pre-sorting / stashing items and running several batches.

[bennlich]

Hmm. Do you mean pre-sorting flat buildings based on color? The problem I'm running into is that my buildings will have dynamic colors, so I would have to re-sort all the time, which probably wouldn't be very efficient.

Are you imagining a scenario in which you are only using a few different colors?

I see the setStyle function now and will move the max height change over there.

[bennlich]

As for the name of the flat building max height setting, what about style.min3DRenderHeight or style.minRenderHeight ?

[kekscom]

It's more like having an object with buildings where color is key. With OSM data, few colors is common.

As mentioned earlier, I think animated properties are killing performance. Therefore I see these as an extension.

Viele Grüße Jan Marsch

Am 07.07.2013 um 03:56 schrieb Benny Lichtner notifications@github.com:

Hmm. Do you mean pre-sorting flat buildings based on color? The problem I'm running into is that my buildings will have dynamic colors, so I would have to re-sort all the time, which probably wouldn't be very efficient.

Are you imagining a scenario in which you are only using a few different colors?

I see the setStyle function now and will move the max height change over there.

— Reply to this email directly or view it on GitHub.

[kekscom]

For the options name: I'm not excited and I have not better idea yet. But the direction: yes. I've been experimenting with some algorithms in order to adapt such things according to frame rate. It's not mature yet.

[bennlich]

I see what you're saying about using an object that can be indexed by color. I'll play around with it and see what works performance wise. It's possible that building that index several times a second won't be a big problem.

I am not planning to add animation functions to the lib--I agree that that seems extraneous. But it does make sense to me to make accessible things like manual rendering for people who want to make a few changes to their data live, re-render, repeat.

[kekscom]

Great you agree :-) What are your ideas for identifying the building to be modified? Or is it replacing the whole set?

[bennlich]

My GeoJSON files include extra attributes per building, like surface area, volume, etc, which I map to colors. Some of these attributes, like energy use, vary with time. Ideally, I would only recalculate colors for visible buildings, so it could be useful to be able to fetch a list of visible building indices.

Maybe I'll try extending the render function to save visible building indices to a local array. It could also be useful to have a version of the render function for when your bounding box has not changed (e.g. rerender() or something like that; I imagine this would be important for oddityoverseer13's RTS project as well: https://github.com/kekscom/osmbuildings/issues/26#issuecomment-20135338).

What do you think? Can you think of other use cases?

[bennlich]

A marginally related display customization: https://github.com/kekscom/osmbuildings/blob/master/src/Data.js#L71-L74

Currently, the linked lines causes some buildings to disappear as you zoom further and further out. Seems like it might make more sense to move those buildings that would disappear over to FlatBuildings, instead of removing them entirely?

[dkniffin]

@bennlich Yes, that would be of use to me. I'll need some way so that a specific building (one that has been clicked) will change color or style, so that it stands out from the others.

btw, sorry I haven't been able to put in any time to help with this. I've been on vacation lately, and haven't been in front of the computer all that much.

[kekscom]

GeoJSON: I like the approach from LeafletJS, there is a callback to a custom function on each feature accessed. There you can re-style or change properties etc. Downside is, such call during render time makes everything unusable slow. For performance reasons I'm considering something about recalculating changed items only. This got more imminent with data tiles subsequently appearing. But ideas are not mature yet.

Disappearing buildings: I'd like to go the opposite direction and would like to remove even more buildings. I.e. here http://osmbuildings.org/?lat=52.50066&lon=13.29955&zoom=16 I don't see a point for having those very low buildings (at this zoom level), but rendering is very slow.

[bennlich]

No worries @oddityoverseer13 ! Looks like we're still doing a good amount of brainstorming.

[bennlich]

Re: disappearing buildings, slow rendering is annoying, but disappearing buildings can be a little misleading. When I see an area void of buildings, I usually assume that the data for that region is missing. In any case, I think it would make sense for the sensitivity to be customizable, no?

It might also make more sense for the visibility to depend on the area (in pixels) of the footprint, as opposed to the display height.

[kekscom]

Ok, I see your point. Suggestions: use a tileset with building footprints visible. That's standard and best performance wise. Alternatively move buildings over to flat - or something beneath that - but for sure without shadows. Flat layer still has shadows. Ideally something that is changed and rendered very rarely. I'll consider changing FlatBuildings into that!

Regarding data, last thoughts are: not to clone data for general rendering but creating a specific index for each layer. Each index item also points to the original item, which is good for you and for some upcoming ideas as well..

For retrieval, it's costly to rearrange that by current viewport, but you could get the whole data set plus viewport bbox in order to filter in your app. Makes sense? Eventually a public method can do the things for you..

[bennlich]

Oops. Closing this since I messed up the commit. I'm still planning to think more about dynamic building colors--I just move at a very slow pace =P

[kekscom]

At least clickable buildings are a top requested feature..