> (we're too many levels deep on hn, so replying to myself - this may end up going beyond what would be a good discussion on hn though)

Where would you like to move the conversation?

> viewing a map, where you can zoom in and out, as well as pan around should probably use javascript. I'd be interested in hearing how you would solve that use case without using javascript.

Using a browser-only solution? First, I'd ensure that navigation buttons (forms) are available which could load a new page if the browser doesn't support features. Then, I'd augment HTML.

First, declare an image tag. <img>. Then add an attribute indicating that it's a sub-view of a larger logical image which can be stitched together (panning), and another attribute indicating it can be zoomed in/out; the attributes should include urls to retrieve new/additional images. If the user pans or zooms too far, the browser can either deny the change that the user tried to do (eg, the image stops panning/zooming) and/or present information to the user indicating why it can't fulfill the request.

This is, in my opinion, a superior solution since it explains to the browser exactly what it is that you want to allow the user to do. Then we don't need to require the user to run (unaudited, unsigned, untrusted) javascript code.

> a city's building footprints, loaded from a feature service (~150mb as JSON), processed by a user-specific variable (such as age of building, square feet, building usage: store, warehouse, residential) where each building is rendered on an interactive map in different colors based on the visualization type.

That sounds cool other than (I assume) 150mb being downloaded onto the user's device before anything can be rendered. I'd build a native application or a server-side application. I also hope that 150mb of data isn't sensitive to whether or not a user inspects it (no secrets or privileged information, for example).

> it can be rendered in browser. without using web workers, expect a 5 minute freeze while everything loads, gets processed, and rendered into the dom, with the experience repeating every time criteria is changed or the map is moved.

First: I think it's audacious to assume that every machine has a lot of CPU resources such that adding web workers magically makes things faster. If a user's device has a single core, then adding web worker's isn't going to make anything magically faster unless the only reason it's slow in the first place is from synchronous communication and execution.

Second: exactly how big is this DOM? When I think of a DOM, I think of a page or two or maybe three at the most. If so much data is being packed into the DOM that it takes minutes for the browser to render it then the DOM is being used for too much. Render an image of it on the server, calculate hotspots that a user could click on, and send the image and hot-spot regions to the client using an HTML map tag. Server then updates the image and sends a new one to the client.

Third: become a VNC server, start a session, and render it in the client using the same technique described above. Speaking from experience, if VNC is less resource intensive and faster then something is going wrong in the development pipeline.

> if this were rendered on the server, it would be quite a lot of server cpu usage to render on the fly

That's a problem... why? You'd rather push the hardware cost onto your user, I take it? I'd rather keep users' and consumer's buy-in costs as low as possible.

> or a huge amount of image space to render ahead of time, plus very large amounts of data. add another layer on top of it, and you're looking at doubling that, along with huge data transfer, which would not make for a very good user experience.

Have you measured it?

Also isn't 150mb considered a very large amount of data? Not everyone has awesome internet connections.

> I'd be interested in hearing an alternate way to provide this, while keeping the data usage, server disk usage, and cpu usage (server and client) to a minimum, while still providing a compelling user experience to the user.

Let me try to understand your project: you want you have an interactive map (ala Google Maps) with an overlay whose color is dynamic based on user selection?

It sounds like it could be done by using a regular HTML form to load images newly-rendered by the server. An added bonus would be allowing the user to navigate forward and backward among their selections using the browser's native navigation features.

Exactly why is it so expensive to render on the server? Exactly how much larger are these map images with data overlaid compared to the original map image? I would think that, generally, when you replace high-color-range data (eg, satellite images) with flat colors (overlays), you'd typically reduce image size (flat colors being compressible); regular map images (plain background, roads and features in solid colors, etc) are pretty small. JPGs and PNGs aren't very expensive (image size) at all compared to that 150mb. I would be extremely surprised if the user was pulling more than 150mb of images for a typical session navigating around a map and making analysis colorization selections.

If your server can't perform with basic image manipulation (take image, overlay a color, return result) then your server software and/or hardware needs some better developer/hardware resources assigned.

Regardless, it sounds like the issue you're trying to get at is the dynamic overlay. Again, I'm not a web developer, but doesn't HTML and CSS already support overlaying images on top of each other? How expensive do you think it would be to serve the underlying map images and, separately, serve pre-rendered overlay images?

I'd imagine the overlay images would be a single color so they should be really small. Not only that, but you can pre-render each building's footprint in black-and-white. Then when serving the pre-rendered image, change the color index/table/palette so that the foreground (black? white? doesn't matter) is whatever color you want to serve. I've not done image manipulation for about 15 years but GIF sounds perfect for this. Then the overlay just needs to go to the exact same coordinate as the underlying map image.

And, hell, just because I like to hate on javascript: let's go back to augmenting HTML. In the form tag, add an attribute to indicate that submitting the form should merely refresh a particular image with a specific name attribute. Then, when submitting the form to change the stats being shown, refresh overlay images only.