Who they are
Postcard is a travel-discovery app that helps people find places worth visiting. Journo is the pipeline that feeds it place recommendations extracted from publishers.
All case studies
11 / Case study · Postcard.inc · Journo
Place-Extraction Pipeline for Postcard
From articles to places people can discover.
What they set out to do
Postcard needed a continuing stream of place recommendations pulled from many publishers, cleaned and matched to real locations, so the app could keep growing its catalog without manual entry.
The problem they were living with
Postcard needed a continuing stream of place recommendations from different publishers. Each source had its own website and data structure, while the extracted place names needed cleaning, filtering and cross-referencing before they could become useful app data.
What it was costing them. Each publisher had its own site and data structure, and extracted place names needed cleaning, filtering and cross-referencing by hand before they were usable. Without a pipeline, the catalog grew only as fast as someone could type.
What changed
- New publishers added by registering a source
- Place names matched to coordinates automatically
spaCy, SerpApi and Who’s On First data turn a mention into a located place.
- Weak matches filtered by a configurable threshold
- Operators watch every run from a dashboard
Journo is a public implementation archive from May 2023. These outcomes describe what the system does; no usage figures are claimed.
Designed solutions
What we designed for Postcard’s people.
Source-specific crawling
Custom crawler functions collect content from each publisher’s website.
HTML and JSON parsing
Parser modules extract relevant place information from each source’s structure.
NLP and location matching
spaCy enriches location context before matching through SerpApi and cross-referencing coordinates with Who’s On First data.
Scoring, identifiers, and filtering
Candidate matches are scored on names, descriptions, contacts and websites. A unique place ID avoids duplicate work, and a configurable threshold filters weaker matches.
Operator dashboards
Postcard’s operators see source and workflow status from the frontend and backend dashboards.
Extensible processing
Source registration and configurable parallelization let the system take on more publishers and different hardware.
The workflow
How the work flows now.
Register a source
An operator connects a source identifier with its crawler and parser.
Collect and parse
The pipeline crawls the content and extracts the relevant location information.
Match and refine
Records are cross-referenced, cleaned and filtered.
Review progress
Operators follow the processing state through the dashboard.
Prepare for Postcard
Structured place data is produced for the downstream integration.
The interfaces
A closer look at what the team uses.
Where else this applies
The same approach, in other industries.
| Industry | Fit | Why |
|---|---|---|
| Local discovery apps | High | The same extraction-and-match loop keeps a places catalog growing from published content. |
| Travel publishers | High | Editorial recommendations become structured, mappable data without retyping. |
| Real-estate listings | Medium | Place matching and de-duplication apply directly to scattered listing sources. |
| Event aggregators | Medium | Venues named in listings can be resolved to coordinates the same way. |
| Research data collection | Emerging | Crawl, parse and cross-reference steps fit many document-to-dataset problems. |
Kevin’s part
Kevin designed and implemented the whole system, frontend and backend; the public repository is inspectable.
Built with. React · Next.js · TypeScript · Python · Django · spaCy · SerpApi · Who’s On First
How I think about work like this
Working on something like Postcard’s?
Tell me where the workflow breaks today and who carries it. I’ll tell you what the smallest useful slice would be, and whether I’m the right person to build it.