combine `geoframe create` for attribute layer and shapes in one line

[asjadnaqvi]

First of all, the package is looking great! I am testing it on my own files to reproduce the maps I typically generate for courses.

It will be great if geoframe create and geoframe attach can be reduced to one line. For example:

geoframe create <attribute_file> <shapefile>, [options id(_ID)] etc.

This would subsume the attach option and also fix #1. In the background the program can also check for existence of map specific variables (_ID, _X, _Y, CX, _CY) etc and make provide a summary statistics of the merge status (this is mostly a quality of life feature).

[benjann]

Ok, I see, you want this to be even simpler. In a way, the problem is that the attribute file can be linked into the shapefile (such that the attributes will be available as variables in the shapefile), but not the other way round. In this logic, the shapefile is the main file, and the attributes file is an add-on. However I see that a user perspective will typically be that the attribute file is the main file and the shapefile is an add-on containing additional info on each unit.

On the other hand, for some times of units (say rivers, roads, etc.) we might have a perspective where the attributes file is rather irrelevant (because there are no relevant attributes in the first place) and we would be happy to directly work with the shapefile. So maybe it would be good to support both perspectives.

An idea would be something like

geoframe create <frname> using <attribute_file> [, shapefile(<shapefile>) ... ]

or

geoframe create <frname> using <attribute_file> [<shapefile>] [, ... ]

If <shapefile> is specified (or maybe even automatically if a *_shp.dta file with the same basename file is available in the same folder as the attribute file), two frames will be created, <frname> and say <frname>_shp, and a link between them will be established (possibly only by recording in frame <frname> the information that the shapes are available in <frname>_shp without necessarily creating a physical link, although the validity of the link should at least be checked). In standard applications, the user would then not have to bother about <frname>_shp and could just call <frname> in geoplot. If shapes are needed (i.e. in plot types area and lines), geoplot would then look whether a link to a shapefile exists in <frname> and will flip things around in the background as needed. This could work, I guess. It would also make the use of alias variables, which are only available in Stata 18, unnecessary (although I would probably still want to keep this functionality). Overall, the message probably is that the system should be set up in a way such that from a user's perspective the attribute file and the shapfile are a single thing, not two, at least in standard applications. Does this make sense to you?

[asjadnaqvi]

Those options make a lot of sense. But automatic linking might not be good idea although it is most likely to work in most cases. It is fairly normal to have different versions of the _shp.dta file, for example, with different projections, or subsets of the whole map. Users might also want to use different parts of the same map in different ways. e.g. a heatmap of German regions in one colorpalette vs a heatmap of France in another colorpalette.

[benjann]

I now revised the geoframe system. geoframe create now has a shpfile() option to load a shape file along with an attribute file. shpfile() runs automatically if geoframe create is applied to an attribute file created by spshape2dta (spshape2dta adds the name of the shape file in the characteristics of the attribute file, which is read by geoframe create); type noshpfile to prevent this behavior. To make things easier for users, geoframe now has a new way to handle linked attribute and shape frames; in geoplot users no longer have to work with the shape frame; they can work directly with the attribute frame and shapes are grabbed automatically. There are also various other changes; see the release notes.