kocheez75

If your data is already in GeoJSON, you can use tippecanoe to produce a tileset in either MBTiles or PMTiles format: https://github.com/felt/tippecanoe.

Or if your data is more dynamic, you can also use the ST_AsMVT extension to query PostGIS, which will generate tiles on-the-fly: https://postgis.net/docs/ST_AsMVT.html

The maps are based on MapLibre (Mapbox fork) so any valid Mapbox style can also be applied.

Ah, sorry to hear about that! I actually just pushed a fix for a similar crashing issue in Firefox, would be curious to hear if that resolved your issues as well.

Thanks!

I moved the createBuffer call out of the render loop, and I think the memory issues on FF should be working better (at least on FF 103).

Great pointers, I’ll give these a shot. Still new to this so appreciate the suggestions!

I believe Protomaps[1] might be what you’re looking for.

[1]: https://protomaps.com/

Good callout, I’ll add that in. Most map libs add that automatically, so an oversight on my part.

Yeah, that’s precisely why I didn’t tackle that. I was wondering though, does it render text in GL on the web, or leverage the DOM? (I’m just using absolute positioning for the tile labels)

Interesting, my hunch would be something about the webgl buffers not getting freed, since they’re running in a tight loop. I’ll do some digging.

Ah, was afraid that might happen. I’m doing some pretty aggressive CF caching, but it’s running on a very small (single instance) server :(

—- update

Looks like I hit the CF worker limit. Should be back up and running. Thanks for the heads up!

Mostly just because I was using https://webglfundamentals.org/ as my main resource. Will probably take a stab at implementing with WebGPU at some point.

Yeah, I think this is a known issue with hammer.js[1]. I noticed it too, but didn't spend too much time digging in.

[1]: https://stackoverflow.com/questions/42872774/hammer-js-exhib...

Radar | Senior Front End Engineer | New York | Full-time | https://radar.io About us: Radar is location data infrastructure. We help product and growth teams build location-aware app experiences. Over the past 12 months, the Radar SDK has been installed on > 100M devices. We're ~35 employees based out of New York. Well-funded Series B startup.

Radar is looking for a Senior Frontend Engineer to build and help design the Radar web application, including api explorers, open source UI Kits, storybook components, dashboards, documentation, landing pages, and more. The Radar web app allows engineers to build and debug location-based product experiences and explore Radar APIs.

Apply: https://boards.greenhouse.io/radarlabs/jobs/4090484003 Jobs: https://radar.io/jobs

Radar | Senior Front End Engineer | New York | Full-time | https://radar.io

About us: Radar is location data infrastructure. We help product and growth teams build location-aware app experiences. Over the past 12 months, the Radar SDK has been installed on > 100M devices. We're ~35 employees based out of New York. Well-funded Series B startup.

Radar is looking for a Senior Frontend Engineer to build and help design the Radar web application, including api explorers, open source UI Kits, storybook components, dashboards, documentation, landing pages, and more. The Radar web app allows engineers to build and debug location-based product experiences and explore Radar APIs.

Apply: https://boards.greenhouse.io/radarlabs/jobs/4090484003 Jobs: https://radar.io/jobs

Radar | Product Engineer (Web), Lead iOS Engineer | New York, NY | ONSITE | FULL-TIME | https://radar.io/ Radar (https://radar.io) is the location context platform. We help companies build better products and make better decisions with location context.

Radar is defining a new category of app platform. If Stripe is for payments and Twilio is for communications, Radar is for location.

Radar processes 100B+ locations per year from 50M+ devices worldwide. In April 2018, TechCrunch named us a top 12 up-and-coming enterprise startup in NYC (https://techcrunch.com/gallery/up-and-coming-enterprise-star...).

We're based in DUMBO, Brooklyn, New York City.

Apply here: https://radar.io/jobs

In the past, I worked for a firm that had a fairly strict testing culture, and that applied to ios as well. We used kiwi specs, which have more-or-less the same syntax as rspec. In the end though, I think it was probably more trouble than it was worth, due to the ridiculous stubs and mocks you need to accomplish testing certain things (stubbing alloc, for instance).