Do you have the address locations (coordinates) as well? Because Address features have (multi)point geometries, so you would have to create point features from x/y(/z) coordinates using the VertexCreator (and then optionally aggregate).
Do you know the relationship to each building (e.g.: do you know the exact address(es) that exist within each building)? Else you would have to join them spatially using a NeighborFinder or SpatialFilter for instance.
If there is a common ID attribute that allows you to join addresses to buildings and vice versa, you need to use a FeatureMerger that uses this common ID attribute (does not need to have the same name, but the value has to match) as the Join On attributes. Beware of duplicate suppliers: if you have m:n relationships, you need to set "Process Duplicate Suppliers" to Yes and use a ListExploder afterwards. Also note that the FeatureMerger will not overwrite existing attributes! Finally, you'd have to do some renaming of your (format) attributes so that they are equal to what the writer expects, e.g. gml_parent_id (= building ID on the address features and root ID on the building features) and gml_id (= unique address ID on the address features and unique building ID on the building features).
Now the actual writing part will be a lot easier if you have an example CityGML file that also includes Address features. In that case, you can add a CityGML Writer without adding a feature type and choose "Import Feature Types" from the menu to add the Address feature type from some other dataset, so you see all the attributes that you can write. Pay special attention to the relationship between cityobjects and address features, so you can apply that knowledge to your own workflow.
For more information about the relation of Address features to other CityGML features, see the specs.
The possible attributes for the Address features are mentioned
here.
So yes... unfortunately there is no quick and easy answer to this question, but that's CityGML... Conceptually a very nice data format, but not so easy to create/write due to its hierarchical structure, requiring you to establish all the relationships yourself.
Do you have the address locations (coordinates) as well? Because Address features have (multi)point geometries, so you would have to create point features from x/y(/z) coordinates using the VertexCreator (and then optionally aggregate).
Do you know the relationship to each building (e.g.: do you know the exact address(es) that exist within each building)? Else you would have to join them spatially using a NeighborFinder or SpatialFilter for instance.
If there is a common ID attribute that allows you to join addresses to buildings and vice versa, you need to use a FeatureMerger that uses this common ID attribute (does not need to have the same name, but the value has to match) as the Join On attributes. Beware of duplicate suppliers: if you have m:n relationships, you need to set "Process Duplicate Suppliers" to Yes and use a ListExploder afterwards. Also note that the FeatureMerger will not overwrite existing attributes! Finally, you'd have to do some renaming of your (format) attributes so that they are equal to what the writer expects, e.g. gml_parent_id (= building ID on the address features and root ID on the building features) and gml_id (= unique address ID on the address features and unique building ID on the building features).
Now the actual writing part will be a lot easier if you have an example CityGML file that also includes Address features. In that case, you can add a CityGML Writer without adding a feature type and choose "Import Feature Types" from the menu to add the Address feature type from some other dataset, so you see all the attributes that you can write. Pay special attention to the relationship between cityobjects and address features, so you can apply that knowledge to your own workflow.
For more information about the relation of Address features to other CityGML features, see the specs.
The possible attributes for the Address features are mentioned
here.
So yes... unfortunately there is no quick and easy answer to this question, but that's CityGML... Conceptually a very nice data format, but not so easy to create/write due to its hierarchical structure, requiring you to establish all the relationships yourself.
I would stress using an example file as Sander suggested. Try find one online, or write it yourself if you have to, then validate it. It would cost some time, but I'm sure it would be worth it. You could look at the Generate function within the XmlTemplater, but as verbose as CityGML is I'm not sure you'd get a lot of use out of it.
Note that you don't need to have Address as a seperate Feature Type, I think you're also allowed to have it as an element within your Building.
As a possible starting point, the Frankfurt file on this page contains a Building with an Address, though it is sadly in CityGML 1.0.
I would stress using an example file as Sander suggested. Try find one online, or write it yourself if you have to, then validate it. It would cost some time, but I'm sure it would be worth it. You could look at the Generate function within the XmlTemplater, but as verbose as CityGML is I'm not sure you'd get a lot of use out of it.
Note that you don't need to have Address as a seperate Feature Type, I think you're also allowed to have it as an element within your Building.
As a possible starting point, the Frankfurt file on this page contains a Building with an Address, though it is sadly in CityGML 1.0.
I always find that so odd: here we have an open non-proprietary format (of which you know that at least half of Germany is using it) and yet it's so hard to find decent CityGML example files online that demonstrate the functionality you need. And the ones you can find are heavily outdated... Little bit off topic, but did anyone for instance ever find a good example of a CityGML file that contains all LODs?