fix some copy to have a problem statement, i think

Author: jtarchie

written/posts/2025-01-26.md

@@ -1,17 +1,17 @@
 # Efficient API Design: Avoiding Costly External Requests
 
+<div role="alert" class="alert alert-info">
+  <svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" class="stroke-current shrink-0 w-6 h-6"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M13 16h-1v-4h-1m1-4h.01M21 12a9 9 0 11-18 0 9 9 0 0118 0z"></path></svg>
+  <span>Previous article on <a href="/posts/2024-08-30">using Goja</a> provides context and underlying technical details.</span>
+</div>
+
 On a recent project, I built an API that leverages OpenStreetMap data, currently
-focusing on the United States and Canada. The API helps users locate
-neighborhoods they might want to live in. This journey involved several
-iterations of building a web application in read-only mode—a self-imposed
-constraint to avoid relying on external services. Everything operates within a
-contained environment, such as a container or VM.
-
-This constraint led me to optimize an SQLite database containing OpenStreetMap
-data. While I’ve written about
-[compressing SQLite data for read-only databases](/posts/2024-07-02-optimizing-large-scale-openstreetmap-data-with-sqlite)
-in another blog post, the main challenge was enabling users to query and
-correlate geospatial data efficiently.
+focusing on the United States and Canada to search for points of interest near
+each other. The API endpoint for querying that data ran into problems of slow
+response times, both for querying and returning considerable data (megabyte
+payloads), with most of it often discarded on the client side. This post goes
+through the optimization process to have the user experience go from tens of
+seconds to a sub-second experience.
 
 Initially, my front-end implementation included an endpoint that allowed users
 to query OpenStreetMap data in a manner similar to other OpenStreetMap systems.

written/potential/2025-01-29-prompt-creation.md

@@ -1,6 +1,6 @@
-## Using LLMs to Convert Natural Language Queries into Structured Queries
+# Using LLMs to Convert Natural Language Queries into Structured Queries
 
-### Context
+## Context
 
 Over the past year, I have been working on building an application platform that
 supports searching through OpenStreetMap data via an API endpoint and an
@@ -27,7 +27,7 @@ it difficult to present the data in a human-readable and usable way. There can
 be tens of thousands, if not hundreds of thousands, of tags with multiple values
 for each.
 
-### Initial Approach
+## Initial Approach
 
 I wanted to take a different approach: Could I have something that converted a
 user's query, such as "grocery store," and mapped it to predefined tags?
@@ -48,7 +48,7 @@ to exclude mainstream coffee shops to find local businesses? This would require
 maintaining a list of coffee shops to exclude or providing an exclusion
 mechanism for users—making the interface complex.
 
-### Experimenting with LLMs
+## Experimenting with LLMs
 
 Given these limitations, I explored the possibility of using a Large Language
 Model (LLM) to process natural language queries and convert them into structured
@@ -80,7 +80,7 @@ Example query:
 
 [Placeholder for an example with ChatGPT’s result.]
 
-### Integrating LLMs into My Application
+## Integrating LLMs into My Application
 
 With structured JSON working, I incorporated it into my application—a text box
 where users could describe their desired neighborhood, and it would return
@@ -106,7 +106,7 @@ I then asked ChatGPT to refine my prompt:
 
 [Placeholder for shortened example of refined prompt.]
 
-### Enhancing Query Accuracy
+## Enhancing Query Accuracy
 
 To improve accuracy, I identified meaningful OpenStreetMap tags by researching
 community discussions and manually curating a list of about 50 high-value tags
@@ -127,15 +127,15 @@ Testing showed that responses were now more specific. For example:
 
 [Placeholder for resulting query JSON.]
 
-### Handling Geographic Areas
+## Handling Geographic Areas
 
 To improve area selection, I extended the JSON output schema to include multiple
 areas. Instead of requiring users to select one state, I allowed descriptions
 like "Southwestern states" to infer multiple areas.
 
 [Placeholder for a query that includes southwestern states.]
 
-### Optimizing Performance
+## Optimizing Performance
 
 While my implementation worked, optimizations were necessary:
 
@@ -161,7 +161,7 @@ While my implementation worked, optimizations were necessary:
      characters.
    - This prevented excessive API costs and safeguarded against abuse.
 
-### Conclusion
+## Conclusion
 
 By integrating OpenStreetMap data with LLMs, I enabled users to query geospatial
 data using natural language. The system supports filtering, distance