Currently, the import routines for the Draw files (i.e. AN1 files) are not really that useful since if you draw some objects with various line styles and symbols, export it, and then import it, you do not get what you started with. There are those of us out here who would like to create utilities for Street Atlas that can reformat other databases and create objects to populate the Street Atlas AN1 files. It would be nice if Street Atlas itself supported this, but another method that would be quite acceptable would be to have a command line based utility that could take as input a script / command file that provided access to ALL the attributes for the draw objects that one would have if one was using the Street Atlas program with a keyboard and mouse.
Even if they were to make the format of the AN1 file public so that others could develop this, it would probably help. I've looked at GPSBabel, but it does not work quite right either. If you draw a few objects of various lines widths, highlights, and colors in Street Atlas, save the AN1 file, input the AN1 file into GPSBabel and convert it to KML and then convert the KML back to an AN1 file, you do not get exactly what you started with.
Let's say that you first define a command language for the definition of the various map objects that are in an AN1 file. From there, you create a command line based program (let's call it "AN1EXTRACT") that takes the AN1 file as input and outputs a text file that is in this command language. From there, you take yet another command line program (let's call it "AN1CREATE") that inputs this text file and outputs an AN1 file. You should be able to do a binary comparison on these two files and they should match EXACTLY. Of course these two command line programs could be combined into a single program and that program could take a command line argument as to whether to run in EXTRACT or CREATE modes. Something like this:
an1 -mode CREATE -in myobjects.txt -out newfile.an1
an1 -mode EXTRACT -in drawings.an1 -out drawings.txt
With "an1.exe" being the name of the utility. A lot of things just don't need a GUI interface for it. I think this is one of them. It's not something that a user will be doing all that often anyway.