libpostal | C library for parsing/normalizing street addresses | Natural Language Processing library

The default WORKDIR for your base image tiangolo/uvicorn-gunicorn:python3.8 is /app. I believe this is the Dockerfile for the base. When you cloned the repo, you were actually running it in /app.

You can explicitly set WORKDIR / or specify WORKDIR /app/libpostal to successfully run the bootstrap script.

You should also adjust your paths in the RUN commands after cloning since they should be relative. Here are the changes I suggest:

Option 1

That is the holy grail of address parsing, for sure. A few things to consider when attacking this project. First, each country can have their own particular addressing format. As much as it would be nice, there's no standard addressing format.

Here are some good compilations of address formats, but even these don't always agree:

Address formats by Informatica

Address formats by Universal Postal Union

Address formats by a guy who has spent a lot of time thinking about this kind of stuff

Step 1 - Once you have become familiar with all the possible address formats for each country, you can group the formats that are similar and create a regex for each group.

Step 2 - This is critical. Do everything you can to determine the country that the address might pertain to. This will let you know which regex to utilize. If you can't do this, you may end up with many different address candidates.

Step 3 - Using your regex, scan through the source text to determine potential horizons, start and end points for an address. In the USA, addresses typically begin with a house number and end with a zipcode (5 or 9 or eleven digit). In Germany addresses typically begin with a street name and end with a city/state or postal code.

Step 4 - Now scan through that address candidate to determine the various components of the address, based on your understanding of the formatting pattern for that country. Find the following components:

• primary number
• street pre-directional (helps to have an index of all the possible values)
• street name (helps to have an index of all the possible values)
• street suffix (helps to have an index of all the possible values)
• street post-directional (helps to have an index of all the possible values)
• secondary number designator (helps to have an index of all the possible values)
• secondary number
• city (helps to have an index of all the possible values)
• state (helps to have an index of all the possible values)
• postal code

(there are a lot more, but that's a good start)

Step 5 - If you only want to determine a string that looks like an address, you're done. Feed this string into a geocoding tool and get the lat/lon that corresponds to it. Google Maps or OpenStreetMap should be able to do the trick for you.

If you want to know if an address is actually valid (as in matches a known entry in an authoritative dataset, like the local post office) then you'll need to use an address validation tool, like one that you'll find with a simple google search:

Google Search: "address validation"

Full disclosure: I spend a lot of time thinking about this very topic, trying to find different ways to solve it, and explaining it to a lot of people. I work international addresses all day long at SmartyStreets.

I managed to build and save all artefacts into a local folder, e.g. "/app/libpostal/" and then the deployment process is simply copying them to the same folder in a EC2 machine. The key thing is to use ./configure command to specify all the folders to store the artefacts and there is a tricky step where I use my own jpostal_build.sh instead of the default one:

You could do this with clojure.spec. First define some specs that match your maps' :label values:

This is a bit complex as those is a pointer to a list of pointers of chars, something very similar to an array of strings.

You need to iterate the pointers, retrieve the internal pointers and convert those to strings (I'm assuming you can use unmanaged code):

After checking everything in agonizing detail, I found the problem:

When C:\msys64\msys2.exe is executed from the "VS2013 x64 Native Tools Command Prompt", the $PATH variable will end up containing /c/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin, but that is the wrong directory for 64-bit work. Instead the path should contain /c/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64. Once I did that substitution, cl.exe worked fine.

Running vcvars64.bat from within the MSYS environment will not fix the $PATH. The above substitution has to be done manually or from a custom startup script like ~/.bashrc.