FNEWZ — Mapping the Pulse of the Planet
FNEWZ is a map-first world news explorer that turns geo-tagged coverage into a navigable surface: scan the planet, zoom into regions, and move between density and detail using an automatic markers ↔ heatmap mode switch.
FNEWZ — Mapping the Pulse of the Planet
A map-first world news explorer built on GDELT GEO 2.0, featuring automatic marker ↔ heatmap switching, geo-bounded querying, and a fully client-side architecture.
- 1) Problem and product constraints
- 2) Research: why typical news surfaces fail for maps
- 3) Data sources and attribution model
- 4) High-level architecture
- 5) Client-side data pipeline
- 6) Markers ↔ Heatmap switching
- 7) Engineering challenges solved
- 8) Performance strategy
- 9) Data quality notes and guardrails
- 10) Status and roadmap
1) Problem and product constraints
The goal was not “another headlines list”. The goal was a world-scale exploration surface where geography is the primary index, not an optional filter.
- Map-native UX: map movement should directly shape the query and the returned results.
- Fast enough for browsing: interactions (pan/zoom/filter) must stay responsive on commodity devices.
- Static-host friendly: no backend required for an initial deploy; everything runs client-side.
- Clean attribution: FNEWZ is an explorer; outbound links should send users to original sources.
2) Research: why typical news surfaces fail for maps
A. “Just use Google” doesn’t solve the dataset problem
Consumer news surfaces are optimized for human browsing, not for a stable, developer-grade feed. When you need a map-ready item, you need more than a title and a link — you need reliable identity and location.
- Thumbnails: not reliably available in a consistent free/public feed form.
- Canonical URLs: links are frequently wrapped/redirected, which breaks dedupe and clean sharing.
- Lat/Lon: coordinates are not provided as a first-class, consistent signal per story.
B. Bing is not a fit for high-volume geo exploration
For map exploration, you need a geo-first dataset where location is part of the data model — not inferred from a generic search response. Typical free-tier access also doesn’t match the interaction profile of a map product (pan/zoom repeatedly, refetch within constraints, maintain state).
Key insight: to build a world-map news UI, “news” must be treated as an events dataset. That means: location extraction/normalization, stable IDs, deduplication, and viewport-aware querying are core engineering work.
3) Data sources and attribution model
FNEWZ intentionally uses publicly available sources that provide the primitives needed for a geo-first UI: geo-tagged news features, geocoding for user-entered places, and map tiles for rendering.
A. GDELT GEO 2.0 (GeoJSON)
- Role: primary geo-tagged news features (lat/lon, counts, timestamps, source domain, etc.).
- Why it works: location is first-class; results are already shaped like an events feed.
- Output: GeoJSON features → transformed into internal “items” for UI rendering.
B. Nominatim (OpenStreetMap geocoding)
- Role: convert named locations (“Delhi”, “Paris”, “Gaza”) into bounds + lat/lon anchors.
- Why it matters: map search must align with the same bounding box logic used by viewport queries.
C. Map tiles (OSM + CARTO)
- Role: background map rendering (OSM tiles) with a dark tile option (CARTO) for better contrast.
- UX detail: tile choice supports readability of dense heat layers and selection states.
4) High-level architecture
The defining choice is that the browser owns the orchestration: query shaping, normalization, and rendering. This keeps deployment simple and makes iteration fast, but it requires discipline around performance and bounded work.
5) Client-side data pipeline
- Build a bounded query from the visible map bounding box and selected filters.
- Apply guardrails: maxpoints/geores/sortby tuned for predictable payload sizes.
- Fetch GeoJSON features from GDELT GEO 2.0.
- Transform features into internal items:
{id, title, domain, ts, lat, lon, count, url}.
- Prevent duplicates caused by redirects/wrapper links and repeating syndication.
- Reconcile against existing state to avoid re-render churn on minor refreshes.
- Choose markers for low–medium density; switch to heat for dense coverage.
- Selection state stays consistent regardless of mode.
- Render map layer (markers or heat) and list UI (desktop sidebar / mobile bottom sheet).
- Paginate list and keep interaction costs bounded under heavy datasets.
6) Markers ↔ Heatmap switching
FNEWZ uses a density-aware visualization strategy: markers for interpretability and heat for coverage. This is not a cosmetic choice — it’s how the UI remains usable when the same region goes from “20 items” to “20,000 items”.
- Marker mode: optimized for scan + click. You want discrete points and fast selection.
- Heatmap mode: optimized for macro signal. You want density gradients and fast panning.
- Automatic switching: thresholds in
js/config.jsdecide the mode based on result density.
Practical outcome: the map never “dies” from too many DOM elements. Heatmap mode is the safety valve that preserves navigation performance at global scale.
7) Engineering challenges solved
A. Canonical URLs and story identity
News aggregation breaks quickly if you treat “a link” as identity. Wrapper URLs and redirects explode duplicates, damage sharing, and fragment analytics. FNEWZ normalizes outbound URLs and dedupes based on a stable identity model (canonical link + source + timestamp heuristics) so repeated syndication doesn’t overwhelm the UI.
B. Viewport-capped querying (map is the query)
A map product cannot behave like a search page. The visible bounding box is the real filter,
and it changes constantly.
FNEWZ uses movement/zoom thresholds (configured in js/config.js) so it doesn’t
refetch aggressively on every pixel of pan,
while still feeling “live”.
C. Reconciliation instead of brute re-render
Re-rendering everything on each refresh causes jitter and unnecessary CPU work. The client reconciles items against existing state, updates only what changed, and keeps selection stable across refreshes.
D. Responsive split UI (desktop sidebar ↔ mobile bottom sheet)
Map + list is the core interface. On desktop, the sidebar can hold dense controls and pagination; on mobile, the bottom sheet must be draggable, readable, and not block the map. The same underlying state powers both layouts without diverging logic.
8) Performance strategy
- Bounded work per interaction: movement thresholds and maxpoints keep fetch + render predictable.
- Mode-based rendering: heatmap prevents marker DOM explosion.
- Progressive UI updates: status + loading states update immediately; heavy transforms are kept tight.
- State-first architecture: map and list are just views of the same normalized item store.
9) Data quality notes and guardrails
FNEWZ is designed for exploration, not archival verification. With public aggregation data:
- Geo locations can be approximate or wrong (especially for ambiguous place names).
- Headlines can be partial or machine-translated.
- Images (when present) may not match the exact event.
- Users should verify important information with the original source.
10) Status and roadmap
FNEWZ is built as a long-term surface. Next steps focus on stronger identity clustering, better “change detection” between refreshes, and more precise geo resolution where the data supports it — without breaking the simplicity of a static-host deployment.
For technical reviews, partnerships, or implementation discussions, use the Azonova contact form.