ANTLR-Powered Query Engine and Floorplan Parser for Real Estate Data

Some time ago, my colleagues published two deep-dive technical articles that walk through a real challenge we faced: turning chaotic, inconsistent real estate data into something machines and users can actually work with.

If you’ve ever tried to make sense of MLS feeds, build a custom property search, or generate layouts from encoded property plans, you know the pain. This wasn’t a matter of plugging in a library or buying an API. We had to build the underlying parsers ourselves.

Here’s how we did it, using ANTLR to parse both natural-language search queries and symbolic room layout strings, and turn both into structured, executable logic.

Note: I’ll add links to both original articles at the end, in case you want the full breakdowns.

Parsing Natural Language Search with ANTLR (The Full System)

Users rarely search real estate platforms like machines. They type “2-bed house in SF under $800K with parking and no HOA.”  And they expect it to just work -- fuzzy logic, synonyms, ranges, exclusions, the works.

To make this query style viable, we built a fully custom parsing engine using ANTLR, translating human intent into a structured, Elasticsearch-compatible query object.

Step 1: Define a Custom Grammar

We created a grammar that tokenized and structured key search constructs:

• query: expr (AND expr)* ; 
• expr: bedrooms | price | amenity | exclusion ; 
• bedrooms: INT 'bed' ; price: 'under' '$'? INT 'K'? ; 
• amenity: 'with' feature ; 
• exclusion: 'no' feature ; 
• feature: 'yard' | 'HOA' | 'garage' ;

The real version was more complex, handling:

• Multi-word locations (“San Francisco”)
• Nested logic (AND, OR, NOT)
• Grouping with parentheses
• Stopword filtering and implicit operators

Step 2: Parse Tree + Visitor Pattern

ANTLR turned the query into an abstract syntax tree (AST). We walked the tree using a visitor pattern to extract semantics and transform the input into a structured query object:

{
  "bedrooms": { "value": 2, "operator": "eq" },
  "price": { "value": 800000, "operator": "lte" },
  "amenities": ["parking"],
  "exclude": ["hoa"],
  "location": "San Francisco"
}

Step 3: Translate to Elasticsearch DSL

We converted this structure into a working Elasticsearch query using QueryStringBuilder. This included:

• Keyword vs. analyzed text handling
• Synonym matching (e.g., garage ↔️ covered parking)
• Boosted scoring based on metadata
• Partial match tolerance (minimum_should_match)
• Wildcard & fuzzy search for edge cases

Example output:

{
  "query": {
    "bool": {
      "must": [
        { "term": { "bedrooms": 2 }},
        { "range": { "price": { "lte": 800000 }}},
        { "match": { "amenities": "parking" }}
      ],
      "must_not": [
        { "match": { "amenities": "HOA" }}
      ]
    }
  }
}

Step 4: Query Migration + Validation

We also built:

• A query migration tool to re-parse and clean saved queries from older systems
• A validation layer to catch illogical constructs (e.g., bedrooms > 2 or < 1)
• A UI feedback loop so users could understand what failed (and why)

This gave us a real, explainable, flexible system, not a black box.

Parsing Real Estate Layout Strings into Visual Floorplans

On the opposite side of the stack, we had another puzzle: encoded floorplans in the form of symbolic strings like 

CU14R2U17R3

This notation describes spatial layout instructions:

• C = start in center
• U = move up
• R = move right
• Numbers = units of movement

Each directional command + length combo defined part of the room's edge.

Step 1: Symbolic Grammar for Layout Parsing

We wrote an ANTLR grammar to tokenize and parse symbolic paths:

• path: command+ ; 
• command: direction length ; 
• direction: 'U' | 'R' | 'D' | 'L' ; 
• length: INT ;

The AST gave us an ordered series of steps which we interpreted as vector movements.

Step 2: Walk the Tree + Extract Geometry

A visitor class walked the tree and:

• Tracked a (x, y) cursor
• Applied direction deltas (U14 → y += 14)
• Recorded all coordinate points

Example:

[
  {"x": 0, "y": 0},
  {"x": 0, "y": 14},
  {"x": 2, "y": 14},
  {"x": 2, "y": 31},
  {"x": 5, "y": 31}
]

Each polygon defines a room boundary.

We also:

• Grouped edges into rooms
• Labeled zones (e.g. “CU” → Central Unit)
• Computed bounding boxes for rendering offsets

Step 3: Render with Java AWT / JavaFX

Finally, we rendered these layouts using:

• Java AWT for .png/.svg output
• JavaFX for interactive UI during testing

The output was accurate. We could debug layouts, check spatial consistency, and generate diagrams on demand directly from encoded strings.

Final Takeaways

Whether you’re interpreting a user’s fuzzy wish list or decoding a symbolic architectural path, the principles stay the same:

• Define a grammar for your domain-specific input
• Use ANTLR to build a parser
• Walk the parse tree and extract meaning
• Convert it into something useful -- a search query, a shape, a filter, or a visual

More on This (Original Deep Dives)

If you want to see the full implementation or get into the technical weeds, check out the original breakdowns:

• Building a Real Estate Search System with ANTLR - covers grammar definition, AST traversal, query validation, and Elasticsearch DSL generation.
• Transforming Textual Data into Real Estate Visualizations - explains how to parse symbolic layout strings into coordinates and render floorplans using Java AWT/JavaFX.